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Abstract 


This  report  will  present  two  commercial  software  environments  used  to  distribute  and  execute 
real-time  simulations:  QuaRC  and  RT-Lab.  Both  QuaRC  and  RT-Lab  allow  the  user  to  develop 
simulation  models  using  Matlab/Simulink  and  include  hardware,  such  as  data  acquisition  boards, 
to  connect  to  real  vehicles  and  systems.  In  addition,  QuaRC  can  be  used  to  program  embedded 
systems  such  as  wheeled  mobile  robots  and  aerial  vehicles. 

This  report  will  present  formation  flight  models  that  have  been  modified  in  order  to  be  compliant 
to  QuaRC  or  RT-Lab.  The  simulations  are  composed  of  six  to  ten  unmanned  aerial  vehicles,  or 
UAVs,  following  a  commanded  trajectory  while  maintaining  a  prescribed  trajectory.  Models 
presented  also  include  abrupt  fault  detection  and  formation  shape  morphing  on  operator’s 
request.  Vehicle  models  and  dynamics  are  based  on  almost  lighter- than-air  (ALTAV)  vehicles, 
unicycles  and  quadrotor  vehicles.  Low-level  controllers  used  to  stabilize  these  UAVs  are 
feedback  linearization  controllers.  Formation  controller  is  of  leader-to-follower  type.  Simulation 
results  are  displayed  in  real-time  on  a  three-dimensional  viewer  (X-Plane). 

The  feedback  linearization  controller  has  been  implemented  on  an  embedded  computer  on  board 
a  wheeled  mobile  robot  (QBot).  An  infrared  camera  system  (OptiTrack  camera  setup)  is  used  to 
measure  the  QBot’s  position  and  orientation.  This  information  is  then  sent  from  the  base  station 
to  the  wheeled  mobile  robot’s  embedded  computer  using  a  wireless  link  in  order  to  close  the 
low-level  controller’s  loop. 

This  report  will  then  present  major  differences  between  QuaRC  and  RT-Lab  as  well  as 
advantages  and  inconvenient  of  using  either  software  solution. 


Resume 

Ce  rapport  presentera  deux  logiciels  servant  a  executer  des  simulations  distribuees  en  temps  reel; 
QuaRC  et  RT-Lab.  Ces  deux  logiciels  permettent  de  developper  des  modeles  de  simulations  en 
utilisant  Matlab/Simulink.  Ces  logiciels  permettent  egalement  d’executer  des  simulations 
incluant  du  materiel  tel  que  des  cartes  d’ acquisition  de  donnees.  De  plus,  QuaRC  permet  de 
programmer  des  systemes  embarques  a  bord  de  robots  mobiles  et  de  vehicules  aeriens. 

Ce  rapport  presentera  des  modeles  de  vols  en  formations  qui  ont  etc  modifies  pour  etre 
compatibles  avec  RT-Lab  ou  QuaRC.  Les  simulations  presentees  sont  composees  de  six  a  dix 
vehicules  suivant  une  trajectoire  commandee  tout  en  maintenant  la  geometric  prescrite.  Les 
modeles  presentes  montrent  des  capacites  essentielles  au  vol  en  formation  telles  que  la  detection 
et  le  recouvrement  de  fautes  abruptes  ainsi  que  la  modification  de  la  geometric  de  la  formation 
sur  la  demande  de  Tutilisateur.  Les  modeles  de  vehicules  utilises  pour  executer  ces  simulations 
sont  des  vehicules  presque  plus  legers  que  Fair  (ALTAVs),  des  unicycles  et  des  quadrotors. 
Leur  controleur  de  has  niveau  est  une  boucle  de  retroaction  linearisee.  Le  controleur  utilise  pour 
maintenir  la  formation  est  de  type  leader-suiveur.  Les  resultats  de  simulation  sont  affiches  en 
temps  reel  dans  un  engin  graphique  a  trois  dimensions  (X-Plane). 

Le  controleur  par  retroaction  linearisee  a  egalement  etc  implante  a  sur  I’ordinateur  embarque 
d’un  robot  mobile  (QBot).  Un  systeme  de  pistage  par  camera  infrarouge  (Systeme  de  camera 
OptiTrack)  est  utilise  pour  mesurer  la  position  et  1’ orientation  du  QBot  en  temps  reel.  Ces 
informations  sont  par  al  suite  relayees  de  la  station  de  base  au  QBot  via  un  lien  sans-fil  pour 
fermer  la  boucle  du  controleur  de  bas  niveau 
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Ce  rapport  presentera  par  la  suite  les  differences  maj  cures  entre  QuaRC  et  RT-Lab  ainsi  que  les 
avantages  et  inconvenients  d’utiliser  I’un  ou  I’autre  des  logiciels. 
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Executive  Summary 


A  group  of  flying  vehicles  following  a  requested  trajectory  while  maintaining  certain  geometry 
(formation)  can  be  useful  to  execute  several  kinds  of  mission:  automated  aerial  refueling, 
coordinated  bombing,  territorial  surveillance,  multi- vehicle  heavy  lift,  and  low-altitude  cruising 
by  fleets  of  missiles.  A  formation  is  composed  of  2  kinds  of  vehicle:  a  leader  and  followers.  The 
leader  receives  objectives  and  commands  from  an  operator  while  followers  attempt  to  keep  their 
commanded  relative  position  from  neighbors.  Note  that  the  operator  can  either  be  on  board  the 
leader  or  on  a  ground  station. 

This  report  will  present  Real-Time  simulation  models  where  the  user  can  control  de  leader’s 
trajectory.  The  user  can  be  considered  as  an  operator  who  sends  high  level  commands  to  the 
leader  from  a  base  station.  Note  that  complying  to  real-time  constraints  is  important  in  order  to 
demonstrate  the  feasibility  of  the  implementation  of  the  formation  controller  and  the  low-level 
controller  on  actual  hardware. 

The  control  of  a  wheeled  mobile  robot  (QBot)  has  also  been  developed  using  the  QuaRC 
software.  Controllers  are  executed  on  board  the  QBot’s  embedded  computer.  Showing  that 
control  algorithms  are  simple  enough  to  be  implemented  in  real-time  on  embedded  computers. 

This  report  will  present  two  commercial  software  environments  used  to  distribute  and  execute 
real-time  simulations:  QuaRC  and  RT-Lab.  Both  QuaRC  and  RT-Lab  allow  the  user  to  develop 
simulation  models  using  Matlab/Simulink  and  include  hardware,  such  as  data  acquisition  boards, 
to  connect  to  real  vehicles  and  systems.  In  addition,  QuaRC  can  be  used  to  program  embedded 
systems  such  as  wheeled  mobile  robots  and  aerial  vehicles. 

This  report  will  provide  formation  flight  models  that  have  been  modified  in  order  to  be 
compliant  to  QuaRC  or  RT-Lab.  The  simulations  are  composed  of  six  to  ten  unmanned  aerial 
vehicles,  or  UAVs,  following  a  commanded  trajectory  while  maintaining  a  prescribed  trajectory. 
Models  presented  also  include  abrupt  fault  detection  and  formation  shape  morphing  on 
operator’s  request.  Vehicle  models  and  dynamics  are  based  on  almost  lighter-than-air  (ALTAV) 
vehicles,  unicycles  and  quadrotor  vehicles.  Low-level  controllers  used  to  stabilize  these  UAVs 
are  feedback  linearization  controllers.  Formation  controller  is  of  leader-to-follower  type. 
Simulation  results  are  displayed  in  real-time  on  a  three-dimensional  viewer  (X-Plane). 

This  report  will  then  present  major  differences  between  QuaRC  and  RT-Lab  as  well  as 
advantages  and  inconvenient  of  using  either  software  solution. 
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Sommaire 


Un  groupe  de  vehicules  volants  suivant  une  trajectoire  prescrite  tout  en  maintenant  une 
geometric  (formation)  peut  etre  utile  pour  plusieurs  types  de  mission  :  le  bombardement 
coordonne,  la  surveillance  territoriale,  la  levee  multi  vehiculaire  de  poids  lourd,  et  le  vol  a  basse 
altitude  d'une  flotte  de  missiles  de  croisiere.  Une  formation  est  composee  de  deux  types  de 
vehicules  :  Un  maitre  et  des  suiveurs.  Le  maitre  est  le  vehicule  qui  rcfoit  les  objectifs  et  les 
commandes  de  haut  niveau  provenant  d’un  operateur  alors  que  les  suiveurs  sont  des  vehicules 
qui  tentent  de  se  positionner  par  rapport  aux  vehicules  voisins  pour  maintenir  une  geometric. 

Ce  rapport  presentera  des  modeles  de  simulations  en  temps  reel  ou  I’utilisateur  peut  commander 
la  trajectoire  du  maitre  de  la  formation.  L’utilisateur  peut  etre  vu  comme  I’operateur  qui  envoie 
des  commandes  de  haut  niveau  au  maitre  a  partir  d’une  station  de  terrestre.  II  est  a  noter  que  le 
respect  des  contraintes  de  temps  reel  est  important  afm  de  demontrer  la  faisabilite  de 
I’implantation  des  controleurs  de  formation  et  de  bas  niveau. 

Le  controle  d’un  robot  mobile  (QBot)  a  egalement  ete  developpe  en  utilisant  le  logiciel  QuaRC. 
Les  controleurs  de  ce  robot  mobile  sont  executes  sur  I’ordinateur  a  bord.  Montrant  ainsi  que  les 
algorithmes  de  controle  sont  suffisamment  simples  pour  etre  implantes  en  temps  reel  sur  un 
ordinateur  embarque. 

Ce  rapport  presentera  deux  logiciels  servant  a  executer  des  simulations  distribuees  en  temps  reel; 
QuaRC  et  RT-Lab.  Ces  deux  logiciels  permettent  de  developper  des  modeles  de  simulations  en 
utilisant  Matlab/Simulink.  Ces  logiciels  permettent  egalement  d’executer  des  simulations 
incluant  du  materiel  tel  que  des  cartes  d’ acquisition  de  donnees.  De  plus,  QuaRC  permet  de 
programmer  des  systemes  embarques  a  bord  de  robots  mobiles  et  de  vehicules  aeriens. 

Ce  rapport  presentera  des  modeles  de  vols  en  formations  qui  ont  etc  modifies  pour  etre 
compatibles  avec  RT-Lab  ou  QuaRC.  Les  simulations  presentees  sont  composees  de  six  a  dix 
vehicules  suivant  une  trajectoire  commandee  tout  en  maintenant  la  geometric  prescrite.  Les 
modeles  presentes  montrent  des  capacites  essentielles  au  vol  en  formation  telles  que  la  detection 
et  le  recouvrement  de  fautes  abruptes  ainsi  que  la  modification  de  la  geometric  de  la  formation 
sur  la  demande  de  Tutilisateur.  Les  modeles  de  vehicules  utilises  pour  executer  ces  simulations 
sont  des  vehicules  presque  plus  legers  que  fair  (ALTAVs),  des  unicycles  et  des  quadrotors. 
Leur  controleur  de  bas  niveau  est  une  boucle  de  retroaction  linearisee.  Le  controleur  utilise  pour 
maintenir  la  formation  est  de  type  leader-suiveur.  Les  resultats  de  simulation  sont  affiches  en 
temps  reel  dans  un  engin  graphique  a  trois  dimensions  (X-Plane). 

Ce  rapport  presentera  par  la  suite  les  differences  maj  cures  entre  QuaRC  et  RT-Lab  ainsi  que  les 
avantages  et  inconvenients  d’utiliser  Tun  ou  Tautre  des  logiciels. 


1.  Introduction 


This  report  presents  real-time  simulations  of  formation  flight  models.  Figure  1  presents  two 
types  of  formation  geometry.  The  first  formation  is  a  V-Shape  formation  and  the  seeond  is  a 
string  formation.  Formations  are  eomposed  of  2  types  of  vehicles,  Leaders  (L)  and  Followers 
(F).  Arrows  represents  the  information  flow.  In  this  report  it  is  assumed  that  the  information 
flow  contains  the  position  and  the  speed  of  previous  vehicles.  It  is  also  assumed  that  an  operator 
located  in  a  base  station  and  can  send  high  level  commands  such  as  trajectories,  velocities 
command  and  orientation  commands,  to  the  leader.  Followers  attempt  to  maintain  the 
formation’s  geometry  by  relying  on  the  information  flow  available. 


F 


(a) 


(b) 

Figure  1:  UAV  Fonnation  Example 

Simulations  presented  in  this  report  are  based  on  ALTAV  [6],  unicycle  [7]  and  quadrotor  [8] 
models.  Each  UAV  comprises  onboard  system  and  components  such  as  actuators,  control 
surfaces,  engines,  on  board  computers  and  wireless  communication  devices.  It  is  assumed  that 
the  formation  and  low-level  controllers  (feedback  linearization  controller  [9])  are  executed 
onboard  UAV  computer  and  that  the  loop  is  closed  by  onboard  sensors. 

Real-Time  simulations  have  been  developed  using  QuaRC  and  RT-Lab.  Both  products  allow 
developing  models  using  Matlab/Simulink.  Models  can  then  be  converted  to  C++  and  compiled 
using  the  Real  Time  Workshop  compiler.  It  is  also  important  to  note  that  these  software 
solutions  allow  splitting  models  into  smaller  models  in  order  to  distribute  the  computation  task 
on  more  than  one  computer. 

The  feedback  linearization  controller  [9]  has  been  implemented  on  an  embedded  computer 
onboard  a  wheeled  mobile  robot  (QBot).  An  infrared  camera  system  (OptiTrack  camera  setup 
[13])  is  used  to  measure  the  QBot’s  position  and  orientation.  This  information  is  then  sent  from 
the  base  station  to  the  WMR’s  embedded  computer  using  a  wireless  link  in  order  to  close  the 
low-level  controller’s  loop.  The  controller  is  executed  on  board  the  QBot’s  embedded  computer, 
showing  that  the  controller  is  simple  enough  to  be  implemented  in  Real-Time  on  embedded 
computers. 

This  report  will  then  present  major  differences  between  QuaRC  and  RT-Lab  as  well  as 
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advantages  and  inconvenient  of  using  either  software  solutions. 


10 


2.  Distributed  Simulations  Using  RT-Lab 


RT-Lab  is  software  that  allows  developing  simulation  models  that  can  be  executed  in  real-time.  Models 
are  developed  using  Matlab/Simulink.  Models  can  then  be  converted  to  C++  source  code  and  compiled 
using  RT-Lab’s  Real-Time-Workshop  compiler.  RT-Lab  also  offers  to  split  models  into  smaller  models  in 
order  to  distribute  the  computation  task  to  more  than  one  computer  or  more  than  one  CPU  core.  Each 
computation  node  (computer  or  core)  are  called  a  Target.  For  example,  if  a  computer  has  4  cores,  it  is 
possible  to  execute  4  different  models  (one  on  each  core).  This  computer  can  then  support  4  Targets. 

Note  that  RT-Lab  also  offers  target  synchronization.  Synchronization  will  ensure  that  simulation  steps  are 
executed  periodically.  Indeed,  non  synchronized  simulation  models  will  start  a  new  computation  step  as 
soon  as  the  previous  one  is  finished.  It  is  possible  to  synchronize  targets  via  software  or  via  hardware. 
Software  synchronization  is  achieved  using  Target’s  CPU  clock  and  hardware  synchronization  is 
achieved  using  an  I/O  board  clock. 

Note  that  this  report  will  present  software  and  hardware  synchronized  simulations.  The  hardware 
synchronization  board  is  the  NI6602  [14]  board  and  has  been  installed  on  the  computer  called  Target  1 
(hardware  specifications  are  available  at  the  Annex  1). 

Model  separation  is  done  entirely  by  RT-Lab.  RT-Lab  model  separation  is  always  composed  of  at  least 
two  targets:  one  target  is  called  the  console  and  the  other  is  called  the  master.  The  console  serves  the 
purpose  of  giving  an  interface  to  the  user  with  Real-Time  Targets  and  is  executed  on  the  same  computer 
that  compiles  models.  For  example,  the  joystick  controller  and  data  logging  must  be  located  in  the 
console.  The  Target  called  the  master  is  executed  in  Real-Time  on  a  computer  on  which  the  OS  is 
RedFIawk  (real-time  linux)  or  QNX.  Such  targets  will  serve  the  purpose  of  executing  models  in  real-time, 
acquire  computation  timings  and  send  simulation  results  to  the  console. 

Additional  real-time  targets  can  be  added  to  the  simulation.  Those  targets  are  optional,  but  can  prove 
useful  when  simulation  models  require  more  computation  power  than  one  target  can  provide.  Indeed,  it  is 
possible  to  distribute  the  computation  task  to  additional  targets  called  slaves  and  thus  reducing 
computation  requirements  to  the  master  target. 

RT-Lab  provides  Simulink  blocks  that  can  be  used  for  fast  prototyping.  For  example,  RT-Lab  provides 
joystick  blocks  allowing  the  user  to  include  a  game  controller  to  simulation  models.  RT-Lab  also  provides 
communication  blocks  allowing  the  user  to  exchange  data  in  real-time  between  real-time  targets.  RT-Lab 
supports  following  communication  protocols:  Ethemet/UDP,  FireWire  and  Shared  Memory. 

Real-Time  models  can  be  executed  on  computers  with  the  following  operating  systems:  RedHawk,  QNX. 

For  more  information  about  RT-Lab,  refer  to  the  Annex  2:  RT-LAB  Quick  Start  Guide. 

RT-Lab  computers  are  presented  in  Annex  1:  Presentation  of  the  Flardware  (Table  4,  Table  5  and  Table 

6). 
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2,1.  Altav  Convoy  model 


This  model  presents  a  9-vehiele  formation.  The  first  vehiele  is  ealled  the  leader.  Other  vehieles  are  ealled 
followers.  The  formation  geometry  for  this  simulation  is  a  string  shape.  For  example:  the  follower  1 
(UAV  2)  will  stay  behind  the  leader,  the  follower  2  (UAV  3)  will  stay  behind  the  follower  1  and  so  on. 
The  leader  follows  trajeetory  determined  by  the  user.  The  user  ean  eontrol  the  leaders’  heading,  speed  and 
altitude  using  a  joystiek.  ALTAV’s  low  level  eontroller  is  the  feedbaek  linearization  eontroller  [9].  The 
formation  eontroller  used  is  detailed  in  [11].  This  model  also  allows  the  user  to  trigger  an  abrupt  fault  on 
the  UAV  2  at  any  time  during  the  simulation.  UAV  3  will  deteet  the  anomaly  using  the  DAFD  [10]  and 
will  reeover  the  fault  by  following  the  leader  of  the  formation  instead  of  following  the  UAV  2. 
Simulation  results  ean  be  viewed  in  a  three  dimensional  viewer  in  Real-Time  using  X-Plane  8.4  [4] 
software.  Note  that  this  simulation  model  is  exeeuted  at  a  period  of  0.01  s  and  is  software  synehronized. 


The  ALTAV  model  presented  in  this  report  is  based  on  the  original  ALTAV  model  [6]  available  at  the 
DRDC-Valeartier  Preeision  Weapon  seetion. 


Following  model  has  been  delivered  to  the  Preeision  Weapons  Seetion  at  DRDC-Valeartier: 
•  RT-Lab:ALTAVeonvoyTeamFDRSummer2007joystiek(DAFD) 
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2.1,1,  Objectives 


The  ALTAV  model  was  already  an  RT-Lab  compliant  model.  It  as  however  been  modified  in  order  to 
allow  the  user  to  control  the  leader  of  the  formation  with  a  joystick  more  easily.  Previously,  the  joystick 
was  controlling  directly  the  X-Y  trajectory  corresponding  to  the  X-Y  values  of  the  joystick  output.  Now 
the  user  controls  the  velocity  and  the  heading  vehicles  allowing  a  smoother  control  of  the  leader. 


2.1.2.  Block  Diagram 

This  model  is  composed  of  two  targets;  APSEQUANSER  and  Target  1  computers.  APSEQUANSER  is  a 
non  Real-Time  windows  target  that  allows  the  user  to  control  the  leader  with  a  joystick  and  trigger  an 
abrupt  fault  on  the  UAV  2.  The  console  also  logs  simulation  results  and  computation  time.  The  Target  1 
executes  UAVs  1  to  9  models,  low-level  controllers  (feedback  linearization  controller  [9])  and  formation 
controllers  [11]  for  each  vehicles.  The  Target  1  also  receives  trajectory  commands  and  fault  trigger  from 
the  console  using  Ethemet/UDP.  The  UAV  3  model  also  includes  an  abrupt  fault  detector  (DAFD  [10]) 
that  can  detect  abrupt  fault  on  the  UAV  2.  Note  that  the  fault  DAFD  only  uses  the  UAV  2  X  and  Y 
position.  Simulation  results  are  also  displayed  on  a  three  dimensional  viewer  (X-Plane  8.4  [4])  that  is 
executed  on  the  computer  APSERTVIEW.  Note  that  simulation  results  are  transferred  in  Real-Time  from 
the  Target  1  to  APSERTVIEW  using  Ethernet/UDP. 


sc_console  executed  on 
APSEQUANSER 


sm_master  executed  on  T arget  1 
RedHawk  Linux 


UDP 


Figure  2:  RT-Lab  ALTAV  Model 
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2.1.3.  Joystick  Control 

The  Figure  3  shows  the  joystick  controller  developed  for  the  ALTAV.  A  hysteresis  has  been  added  to  the 
altitude  and  the  heading.  This  hysteresis  will  allow  the  user  to  keep  the  same  heading  and  altitude  without 
requiring  the  joystick  to  be  perfectly  centered.  The  altitude  will  increase  if  the  user  pull  the  joystick 
toward  him  or  decrease  if  the  user  pushes  the  joystick. 

The  trajectory  is  then  calculated  as  follows: 

T 

=  j  F  {t)  cos{6{t))dt 
0 
T 

Yj=^V  {t)  sm{0{t))dt 

0 

Where:  V(t)  is  the  requested  velocity  (Joystick’s  throttle  command),  6{t^  the  requested  heading  and  T  is 
the  current  simulation  time.  Note  that  the  requested  heading  0{t)  will  increase  if  the  joystick  is  steered  to 
the  left  and  decrease  if  the  joystick  is  steered  to  the  right.  The  requested  heading  will  remain  still 
otherwise. 


Figure  3:  ALTAV  Joystick  Controller 
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2,2,  RT-Lab  QuadRotor  Models 


This  model  presents  a  6-vehiele  formation  maintaining  a  V-Shape  geometry.  The  first  vehiele  is  ealled  the 
leader.  Other  vehieles  are  ealled  followers.  Followers  will  follow  their  immediate  predeeessors.  As 
shown  on  Figure  4,  UAVs  1  and  2  follow  the  Leader,  UAVs  3  and  4  follow  the  UAV  1  and  the  UAV  5 
follows  the  UAV  2.  The  user  ean  eontrol  the  leaders’  heading,  speed  and  altitude  using  a  joystiek.  The 
user  ean  also  trigger  an  abrupt  fault  on  the  follower  2.  Follower  5  will  then  deteet  the  fault  (using  the 
DAFD  [10])  and  follow  the  leader  instead  of  following  the  Follower  2.  The  low  level  eontroller  is  a 
feedbaek  linearization  eontroller  [9]  and  the  formation  eontroller  deseribed  in  [11]  is  used  to  maintain  the 
geometry  of  the  formation.  Simulation  results  are  sent  to  X-Plane  8.4  [4]  in  real-time  using  Ethemet/UDP. 
Note  that  this  simulation  model  is  exeeuted  at  a  period  of  0.001  s. 

Note:  The  QuadRotor  model  presented  in  this  report  is  based  on  the  original  QuadRotor  model  [8]. 

The  following  models  have  been  delivered  to  the  Preeision  Weapons  Seetion  at  DRDC-Valeartier: 

•  Formation_6QuadRotors_Fault_fault_deteet.mdl  (Synehronized  by  software) 

•  Formation_6QuadRotors_FaultJoystiek.mdl  (Synehronized  by  software) 

•  Formation_6QuadRotors_FaultJoystiek_FtWSynehro.mdl  (Synehronized  by  hardware 
using  the  NI6602  board) 
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Figure  4:  QuadRotor  formation  topology  (lines  indieate  information  flow) 


2,2,1,  Objeetives 

•  Transform  the  original  Simulink  model  to  a  RT-Lab  eompliant  model 

•  Send  the  data  in  real-time  to  X-Plane  (3d  environment  viewer) 

•Allow  the  user  to  use  the  joystiek  to  eontrol  the  formation 

•Allow  the  user  to  trigger  a  fault  on  the  follower  2  (The  fault  will  be  deteeted  by  the  Follower  5) 

•  Obtain  eomputation  time  of  the  model  on  RT-Lab 
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2.2.2.  Block  Diagram 


This  block  diagram  presents  how  the  model  is  distributed.  The  simulation  was  distributed  on  one  Real- 
Time  target  and  one  Non-Real-time  Target  (Console).  The  model  named  sc  console  has  the  task  to 
acquire  joystick  commands,  allow  the  user  to  trigger  a  fault  on  the  UAV  2  and  log  the  simulation  statistics 
(Simulation  Step  Size,  Communication  statistics).  Each  of  the  6  UAVs  is  simulated  on  the  model 
sm  master.  The  computer  named  Target  1  is  executing  the  model  sm  master.  The  computer  named 
APSEQUANSER  executes  the  model  called  sc  console.  The  computer  named  APSERTVIEW  displays 
simulation  results  in  Real-Time  on  X-Plane  8.4  [4].  Note  that  simulation  results  are  sent  to  X-Plane  from 
the  Target  1  using  an  Ethemet/UDP  link.  For  more  information  computers  hardware,  see  the  Annex  1: 
Presentation  of  the  Flardware. 


sc_console  executed  on 

APSEQUANSER  sm_master  executed  on  Target  1 

(windows)  RedHawk  Linux 


X-Piane  8.4  executed  on 
APSERTVIEW 


Figure  5:  RT-Lab  QuadRotor  model 
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2.2.3.  Joystick  Control 


The  Figure  6  shows  the  joystick  controller  for  the  QuadRotor.  A  hysteresis  has  been  added  to  the  altitude 
and  the  heading.  This  hysteresis  will  allow  the  user  to  keep  the  same  heading  and  altitude  without 
requiring  the  joystick  to  be  perfectly  centered.  The  altitude  will  increase  if  the  user  pull  the  joystick 
toward  him  or  decrease  if  the  user  pushes  the  joystick.  The  heading  will  increase  or  decrease  if  the  user 
steer  the  joystick.  The  requested  velocity  will  be  1.1  m/s  if  the  formation  is  flying  in  a  straight  line  or  2 
m/s  if  the  formation  is  turning.  This  special  velocity  command  will  ensure  that  the  followers  will  keep 
tracking. 


The  trajectory  is  then  calculated  as  follow: 


T 

=  j  F  {t)  QO%{6{t))dt 
0 
T 

7^  =  j  F  (/)  sm{6{t))dt 

0 

Where:  V(t)  is  the  requested  velocity  (Joystick’s  throttle  command),  6{t^  the  requested  heading  and  T  is 
the  current  simulation  time.  Note  that  the  requested  heading  0{t)  will  increase  if  the  joystick  is  steered  to 
the  left  and  decrease  if  the  joystick  is  steered  to  the  right.  The  requested  heading  will  remain  still 
otherwise. 
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2.2.4,  Results 


The  Figure  7  and  the  Figure  8  show  the  eomputation  time  obtained  in  RT-Lab.  All  these  values  are  in  ps. 
These  5  plots  represent: 

•  Time  spent  by  the  RedHawk  target  to  reeeive  data 

•  Time  spent  by  the  RedFlawk  target  to  send  data 

•  Model  ealeulation  time  (Computing  only) 

•  Effeetive  step  size  (Computing  +  synehronization) 

•  Total  step  size  (Computing  +  overhead  +  synehronization) 


The  Figure  7  shows  the  eomputation  time  for  the  QuadRotor  model  exeeuted  with  a  hardware 
synehronization.  We  ean  see  that  the  eommunieation  timing  is  set  to  0  whieh  means  this  measure  is 
eonsiderably  small.  The  total  step  size  is  around  1000  ps,  whieh  is  normal  beeause  the  sampling  time  is 
set  to  1  ms.  The  minimum  and  maximum  total  step  size  are  998  ps  to  1002  ps  whieh  mean  that  the  jitter  is 
+  2  ps.  The  model  ealeulation  time  and  the  effeetive  step  size  are  varying  from  60  ps  to  85  ps  whieh 
means  the  step  size  eould  be  redueed  to  90  ps  without  risking  having  overruns  in  the  simulation. 


Figure  7:  QuadRotor  model  with  hardware  synehronization  eomputation  timing 
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Figure  8  shows  the  computation  time  for  the  QuadRotor  model  executed  with  a  software  synchronization. 
We  can  see  that  the  communication  timing  is  set  to  0  which  means  this  measure  is  considerably  small.  The 
total  step  size  is  around  1000  ps,  which  is  normal  because  the  sampling  time  is  set  to  1  ms.  The  minimum 
and  maximum  total  step  size  are  998  ps  to  1001  ps  which  mean  that  the  jitter  is  +2  ps.  The  model 
calculation  time  and  the  effective  step  size  are  varying  from  60  ps  to  85  ps  which  means  the  step  size 
could  be  reduced  to  90  ps  without  risking  having  overruns  in  the  simulation. 

Note  that  the  total  step  size  seems  to  be  more  stable  with  the  hardware  synchronization. 
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2,3.  RT-Lab  AFGsummer2007 


This  model  presents  a  6-vehiele  formation.  The  first  vehiele  is  ealled  the  leader.  Other  vehieles  are  ealled 
followers.  Followers  will  follow  their  immediate  predeeessors  in  order  to  maintain  a  V-Shape  geometry. 
The  user  ean  eontrol  the  leaders’  heading,  speed  and  altitude  using  a  joystiek.  The  user  ean  also  order  the 
formation  to  perform  a  shape  morphing.  Indeed,  the  user  ean  order  vehieles  to  inerease  or  deerease 
distanee  between  neighbors.  Low-level  eontroller  are  feedbaek  linearization  eontroller  [9]  and  the 
formation  eontroller  deseribed  in  [11]  has  been  used  to  maintain  the  formation  geometry.  Simulation 
results  are  displayed  in  Real-Time  using  a  three  dimensional  viewer  (X-Plane  8.4  [4]).  Simulation  results 
are  sent  from  a  Real-Time  target  to  the  X-Plane  eomputer  using  an  Ethemet/UDP  link.  Note  that  this 
simulation  model  is  exeeuted  at  a  period  of  0.001  s. 

The  unieyele  model  presented  in  this  report  is  based  on  the  original  unieyele  model  [7]. 

The  following  models  have  been  delivered  to  the  Preeision  Weapons  Seetion  at  DRDC-Valeartier: 

•  RT-Lab  :AFG_summer2007joystiek  (Software  synehronized) 

•  RT-Lab  :AFG_summer2007joystiek2CPUs  (Software  synehronized) 

•  RT-Lab  :AFG_summer2007joystiekFIWsynehro  (Flardware  synehronized) 


2.3.1.  Objeetives 

The  objeetives  of  that  model  are: 

•  Ensure  that  models  were  still  working  in  RT-Lab. 

•  Obtain  the  eomputation  timings 

•  Show  the  simulation  results  in  real-time  on  X-Plane 

Note:  The  model  ean  send  simulation  data  to  X-Plane  in  real-time.  This  feature  is  not  shown  in  this 
doeument. 
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2.3.2,  Block  Diagram 


The  Figure  9  presents  a  block  diagram  of  the  distributed  unicycle  simulation.  The  simulation  was 
distributed  on  two  Real-Time  targets  and  one  Non-Real-time  Target  (Console).  The  model  named 
sc  console  has  the  task  to  generate  a  trajectory  from  the  joystick  command  and  log  simulation  statistics 
(Simulation  Step  Size,  Communication  statistics).  The  leader  and  UAVs  1  to  5  are  simulated  on  the  model 
sm  master.  UAVs  6  to  9  are  simulated  on  the  model  ss  slave.  The  computer  named  Target  1  is  executing 
the  model  sm  master  and  the  computer  named  Target  2  is  executing  the  model  ss  slave.  The  computer 
named  APSEQUANSER  executes  the  model  called  sc  console.  The  computer  named  APSERTVIEW  is 
used  to  display  simulation  results  in  Real-Time  using  X-Plane  8.4  [4].  For  more  information  computers 
hardware,  see  the  Annex  1 :  Presentation  of  the  Flardware. 


5Q_sflasa!8  axsautad  on 

APSEQUANSER  sm..magter  executed  on  Target  1 

(KOnsJiMS)  BSSJUaiMk  Linux 


SS-Sias®  axssutad  on  Target  2 
BSSjtMS  Linux 

Figure  9:  RT-Lab  AFG  summer  2007  distributed  on  2  CPU  block  diagram 
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The  Figure  10  presents  a  bloek  diagram  of  the  unieyele  simulation.  The  simulation  was  distributed  on  one 
Real-Time  target  and  one  Non-Real-Time  Target  (Console).  The  model  named  se  eonsole  has  the  task  to 
generate  a  trajeetory  from  the  joystiek  eommand  and  log  simulation  statisties  (Simulation  Step  Size, 
Communieation  statisties).  The  leader  and  UAVs  1  to  8  are  simulated  on  the  model  sm  master.  The 
eomputer  named  Target  1  is  exeeuting  the  model  sm  master.  The  eomputer  named  APSEQUANSER 
exeeutes  the  model  ealled  se  eonsole.  The  eomputer  named  APSERTVIEW  is  used  to  display  simulation 
results  in  Real-Time  using  X-Plane  8.4  [4].  For  more  information  eomputers  hardware,  see  the  Annex  1: 
Presentation  of  the  Flardware. 


sc_console  executed  on 

APSEQUANSER  sm_master  executed  on  Target  1 

(windows)  RedHawk  Linux 


X-Piane  8.4  executed  on 
APSERTVIEW 


Figure  10:  RT-Lab  AFG  summer  2007  bloek  diagram 
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2.3.3.  Results 


The  Figure  11  shows  the  computation  timing  for  the  AFGSummer  2007  model  with  software 
synchronization. 

These  5  plots  represent: 

•  Time  spent  by  the  RedFlawk  target  to  receive  data 

•  Time  spent  by  the  RedFlawk  target  to  send  data 

•  Model  calculation  time  (Computing  only) 

•  Effective  step  size  (Computing  +  synchronization) 

•  Total  step  size  (Computing  +  overhead  +  synchronization) 

We  can  see  that  the  communication  timing  is  set  to  0  which  means  this  measure  is  considerably  small.  The 
total  step  size  is  around  1000  ps,  which  is  normal  because  the  sampling  time  is  set  to  1  ms.  The  minimum 
and  maximum  total  step  size  are  998  ps  to  1001  ps  which  mean  that  the  jitter  is  +2ps.  The  model 
calculation  time  and  the  effective  step  size  are  varying  from  40  ps  to  80  ps  which  means  the  step  size 
could  be  reduced  to  85  ps  without  risking  having  overruns  in  the  simulation. 


Figure  11:  RT-Lab  timings  for  AFGSummer2007 
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Figure  12  shows  the  eomputation  timing  for  the  AFGSummer  2007  model  with  hardware  synehronization. 

We  can  see  that  the  communication  timing  is  set  to  0  which  means  this  measure  is  considerably  small.  The 
total  step  size  is  around  1000  ps,  which  is  normal  because  the  sampling  time  is  set  to  1  ms.  The  minimum 
and  maximum  total  step  size  are  988  ps  to  1010  ps  which  mean  that  the  jitter  is  ±  12  ps.  The  model 
calculation  time  and  the  effective  step  size  are  varying  from  40  ps  to  80  ps  which  means  the  step  size 
could  be  reduced  to  85  ps  without  risking  having  overruns  in  the  simulation. 


Figure  12:  RT-Lab  timings  for  AFGSummer2007  with  hardware  synchronization 
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Figure  13  shows  the  computation  timing  for  the  AFGSummer  2007  model  distributed  on  2  computers 
with  software  synchronization.  On  the  left  side,  the  SM  Master  timings  are  shown.  On  the  right  side,  the 
SS  Slave  timings  are  shown. 

The  computing  time  of  the  master  target  reaches  70  ps  and  the  slave  reaches  18  ps.  The  effective  step  size 
of  the  master  reaches  75  ps  and  the  slave’s  is  the  same  as  the  effective  step  size  since  the  slave  is 
synchronizing  with  the  master. 

The  minimum  and  maximum  total  step  size  of  the  slave  is  987  ps  to  1013  ps  which  mean  that  the  jitter  is 
+  13  ps.  The  minimum  and  maximum  total  step  size  of  the  maser  is  990  ps  to  1010  ps  which  mean  that 
the  jitter  is  +  10  ps. 

These  data  shows  that  the  step  size  could  be  lowered  to  80  ps.  The  simulation  step  size  could  be  lowered 
when  distributing  models. 


Figure  13:  RT-Lab  timings  for  AFGSummer2007  distributed  on  2  CPUs 
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3.  QuaRC  Models 


The  QuaRC  software  allows  developing  simulation  models  using  Matlab/Simulink.  Models  can  then  be 
converted  to  C++  and  compiled  using  the  QuaRC  Real-Time-Workshop  compiler.  Each  QuaRC  Models 
can  be  executed  in  real-time  or  in  a  regular  Simulink  simulation.  Note  that  a  QuaRC  Target  is  simply  a 
computer  on  which  QuaRC  is  installed.  Note  that  more  than  one  model  can  be  executed  on  the  same 
Target  (or  same  computer).  Indeed,  a  computer  with  one  core  can  execute  2  models  simultaneously  in 
Real-Time. 

QuaRC  provides  Simulink  blocks  that  can  be  used  for  fast  prototyping.  For  example,  QuaRC  provides 
joystick  blocks  allowing  the  user  to  include  game  controllers  to  models.  QuaRC  also  provides 
communication  blocks  allowing  data  to  be  exchanged  between  QuaRC  Targets.  QuaRC  communication 
blocks  can  also  be  used  to  exchange  data  between  QuaRC  targets  and  non  QuaRC  targets. 

Note  that  users  must  separate  manually  models  and  configure  communication  blocks  in  order  to  distribute 
models.  Indeed,  unlike  RT-Lab,  QuaRC  users  must  configure  communication  parameters  manually  such 
as  IP  addresses  and  port  numbers  in  order  to  exchange  data  between  models. 

In  RT-Lab,  Targets  can  be  console,  master  or  slaves  (refer  to  the  section  2  for  more  information).  In 
QuaRC,  there  is  no  such  a  distinction.  Indeed,  QuaRC  models  do  not  require  a  Non  Real-Time  model  to 
be  executed  in  order  to  change  simulation  parameters.  Simulation  parameters  can  be  changed  directly  in 
the  Simulink  model  during  the  execution. 

Real-Time  models  can  be  executed  on  computers  with  the  following  operating  systems: 

•  Windows 

•  QNX 

•  Embedded  QuaRC  Target  (Linux  ARM) 


3.1.  QuaRC  QuadRo tor  Model 

This  model  presents  QuadRotors  executing  a  V-Shape  formation  flight.  The  formation  is  composed  of  10 
QuadRotors.  The  user  can  control  the  leader’s  velocity,  heading  and  altitude  using  a  joystick.  Followers 
will  attempt  to  follow  the  leader  and  maintain  the  prescribed  geometry.  The  user  can  also  trigger  an  abrupt 
fault  on  the  UAV  3.  The  UAV  5  will  then  detect  the  fault  on  the  UAV  2  using  the  DAFD  [10]  and  follow 
the  leader  instead  of  following  the  UAV  3.  Low  level  controllers  used  to  stabilize  vehicles  are  feedback 
linearization  controllers  [9].  The  formation  controller  used  to  maintain  the  formation  geometry  is  given  in 
[11].  Note  that  this  simulation  model  is  executed  at  a  period  of  0.001  s. 


This  model  has  been  delivered  to  the  DRDC-Valcartier  Precision  Weapons  Section. 

This  simulation  model  is  based  on  the  original  Simulink  QuadRotor  model  [8]. 

3.1.1.  Objectives 

The  objectives  of  that  model  are: 

•  Simulate  the  QuadRotor  model  on  a  Windows  Real-Time  Target 

•  Allow  the  user  to  use  the  joystick  to  control  the  leader  of  the  formation 

•  Show  that  the  fault  on  the  UAV  2  can  be  detected  an  recovered  by  the  formation 
using  the  DAFD  [10]  on  board  the  UAV  5 

•  Send  the  data  in  Real-Time  to  X-Plane  (3d  environment  viewer) 
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3.1.2.  Block  Diagram 

The  Figure  14  presents  the  QuaRC  QuadRotor  block  diagram.  A  joystick  is  connected  to  the  computer 
APSEQUANSER.  The  user  can  use  the  joystick  to  control  the  trajectory  of  the  leader.  Followers  will 
attempt  to  follow  the  leader  and  hold  a  V-Shape  geometry  as  shown  on  the  Figure  15.  The  computer 
APSEQUANSER  will  then  send  simulation  results  to  the  computer  APSERTVIEW  using  an 
Ethemet/UDP  link,  where  UAVs  are  displayed  in  Real-Time  on  X-Plane  8.4  [4]  .For  more  information 
computers  hardware,  see  the  Annex  1 :  Presentation  of  the  Hardware. 
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Figure  14:  QuadRotor  Block  Diagram 
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Figure  15:  QuadRotor  fleet  topology  (lines  indicate  information  flow) 
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3.1.3.  Plots 


Figure  16  to  Figure  18  show  the  2D  trajectory  of  simulated  QuadRotors  at  different  simulation  instants. 
The  black  dashed  line  represents  the  leader’s  requested  trajectory.  The  blue  dotted  line  represents  the 
trajectory  of  the  UAV  3  (follower  2)  and  the  blue  dashed-dotted  line  represents  the  UAV  5  trajectory.  An 
abmpt  fault  has  occurred  on  this  UAV  after  79  second.  On  the  Figure  17,  we  can  see  that  the  UAV  5  has 
detected  the  fault  and  maintain  his  relative  position.  On  the  Figure  18,  we  see  that  the  UAV  5  now  follows 
the  Leader.  The  UAV  5  detected  a  fault  on  the  UAV  2  using  only  UAV  2’s  X-Y  position  and  speed  and 
the  DAFD  [10].  It  is  important  to  note  here  that  the  trajectory  was  generated  by  a  joystick  and  that  the 
formation  shape  has  been  maintained  using  the  formation  controller  of  [11].  A  fault  has  been  trigged  on 
the  UAV  3  at  a  random  time  by  the  user  and  has  been  detected  in  real-time  during  the  simulation  using  the 
DAFD  [10]  (abrupt  fault  detector).  The  formation  has  then  adapted  its  topology  to  recover  from  the  fault. 


Figure 


16: 


QuadRotor  X-Y  Trajectory 


at 


79 


second  of  simulation 


28 


50 


40 

30 

20 

10 


-20 

-30 

-40 


■g| - i - 1 - i - i - 1 - 1 - 1 - i - i - 1 

-10  0  10  20  30  40  50  60  70  80  90 

X(m) 


- Trajectory 

- UAV1 

UAV2 

. UAV  3 

UAV4 

- UAV  5 

- UAV  B 


Figure  17:  QuadRotor  X-Y  Trajectory  at  1 18  second  of  simulation 


50 
40 
30 
20 
10 

^  0 
>- 

-10 
■20 
-30 
■40 
-50 

-10  0  10  20  30  40  50  60  70  80  90 

X(m) 


- Traj 

ctory 

1 

2 

'3 

4 

UAN/ 

UA\ 

. UA\ 

UA\ 

- UAV  5 

- UAV  6 

- -i - ---o 

Figure  18:  QuadRotor  X-Y  Trajectory  at  158  second  of  simulation 
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3.2,  QuaRC  Distributed  QuadRotor  model 


This  model  presents  six  QuadRotor  exeeuting  a  V-Shape  formation  flight.  The  user  ean  eontrol  the 
leader’s  veloeity,  heading  and  altitude  using  a  joystiek.  Followers  will  attempt  to  follow  the  leader  and 
maintain  the  formation  geometry.  This  simulation  is  eonstituted  of  three  Real-Time  models  exeeuted  on  2 
Real-Time  targets.  The  model  is  distributed  as  follow:  The  eonsole  allows  the  user  to  eontrol  the  leader’s 
trajeetory,  trigger  a  fault  on  the  UAV  3.  The  eonsole  also  sends  simulation  data  to  X-Plane  8.4  [4]  in 
Real-Time  using  an  Ethemet/UDP  link.  In  this  simulation,  the  leader  is  exeeuted  on  the  first  target  and 
followers  are  exeeuted  on  the  seeond  target.  The  UAV  5  ean  deteet  abrupt  faults  on  the  UAV  2  using  the 
DAFD  [10]  and  reeover  by  following  the  leader  instead  of  following  the  UAV  2.  The  QuadRotor  low- 
level  eontroller  is  the  feedbaek  linearization  eontroller  in  [9].  The  V-shape  geometry  is  assured  by  the 
formation  eontroller  [11].  Note  that  this  simulation  model  is  exeeuted  at  a  period  of  0.001  s. 

This  model  has  been  delivered  to  the  DRDC-Valeartier  Preeision  Weapons  Seetion. 


3.2.1,  Objeetives 


•  Distribute  the  eomputing  power 

•  Separate  the  leader  model  from  the  followers 

•  Send  the  data  in  Real-Time  to  X-Plane  (3d  environment  viewer) 
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3.2.2.  Block  Diagram 

This  block  diagram  presents  how  models  and  targets  are  organized  to  execute  the  distributed  QuadRotor 
simulation.  Note  that  the  vehicles  are  performing  a  V-Shape  formation  as  shown  on  the  Figure  15.  The 
simulation  was  distributed  on  3  targets.  The  model  named  console  has  the  task  to  generate  the  leader’s 
commanded  trajectory  and  send  simulation  results  to  X-Plane.  The  leader  of  the  formation  is  executed  on 
the  model  named  Target  1  and  followers  are  executed  on  the  model  named  Target  2.  The  computer  named 
APSENLEVFII  is  executing  the  console  and  the  Target  2  model.  The  computer  named  APSEQUANSER 
is  executing  the  Target  1  model.  Simulation  results  are  sent  in  Real-Time  using  an  Ethemet/UDP  link 
from  the  console  model  to  the  three  dimensional  viewer:  X-Plane  8.4  [4]. 

For  more  information  computers  hardware,  see  the  Annex  1 :  Presentation  of  the  Flardware. 

Note  that  in  this  configuration,  there  are  three  Real-Time  models  (Console,  Targetl  and  Target2)  executed 
on  two  Real-Time  Targets  (APSENLECFIEVI  and  APSEQUANSER).  X-Plane  8.4  is  executed  on  a  third 
computer  called  APSERTVIEW. 


Console  Targetl  Target2 

Simulink  Model  Simulink  Model  Simulink  Model 

EjSeOUted  on  APSENLECHEVI  ExeSUtad  on  APSEQUANSER  EJS&GUtSd  on  APSENLECHEVI 


TCP. 


TCP 


Figure  19:  QuadRotor  with  the  leader  and  followers  on  different  targets 
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3.2,3.  Plots 


Figure  20  to  Figure  22  show  the  2D  trajectory  of  simulated  QuadRotors  at  different  simulation  instants. 
The  blue  dotted  line  represents  the  trajectory  of  the  UAV  3  (follower  2)  and  the  blue  dashed-dotted  line 
represents  the  UAV  5  trajectory.  An  abrupt  fault  has  occurred  on  this  UAV  after  94  second.  On  the  Figure 
21,  we  can  see  that  the  UAV  5  has  detected  the  fault  and  maintain  his  position.  On  the  Figure  22,  we  see 
that  the  UAV  5  now  follows  the  Leader.  The  UAV  5  detected  a  fault  on  the  UAV  2  using  the  DAFD  [10] 
on  board  the  UAV  5.  Note  that  the  DAFD  uses  only  the  UAV  2  X-Y  position  and  speed.  Note  also  that 
when  the  abrupt  fault  on  the  UAV  2  is  detected  by  the  UAV  5,  it  begins  to  follow  the  leader  instead  of 
following  the  UAV  2.  On  the  Figure  21  and  the  Figure  22,  we  see  that  the  UAV  5  catching  up  to  the 
leader. 

Note  that  the  trajectory  of  the  UAV  3  has  been  omitted  for  Figure  21  and  Figure  22  because  of  its  erratic 
motion. 
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Figure  20: 


QuadRotor  leader  executed  on  a  separate  target  X-Y  Trajectory  at  94  seconds  of  simulation 


32 


50 


40 

30 

20  - 

10 

I  0 
> 

-10 
-20  - 
-30  - 
-40 


-50 


-10 


-Trajectory 

-UAV1 

UAV2 

UAV3 

-UAV4 

-UAV5 


10 


20 


30  40  50 

X(m) 


60 


70  80 


90 


Figure  21 :  QuadRotor  leader  exeeuted  on  a  separate  target  X-Y  Trajeetory  at  141  seeonds  of  simulation 


Figure  22:  QuadRotor  leader  exeeuted  on  a  separate  target  X-Y  Trajeetory  at  158  seeonds  of  simulation 
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4.  Wheeled  Mobile  Robot  Control  Using  QuaRC  and  Windows  Real-Time  Targets 


The  Quanser  QBot  is  a  wheeled  mobile  robot  provided  by  the  Quanser  Company  [1]  and  shown  on  the 
Figure  23.  The  QBot  as  on  board  an  embedded  eomputer  (GumStix  [12])  that  executes  Linux  ARM 
Operating  System.  This  robot  can  be  programmed  using  Matlab  Simulink  and  Real-Time 
Workshop/QuaRC.  Simulink  models  are  written  in  C++  by  Real-Time  Workshop/QuaRC.  The  C++ 
source  code  is  then  sent  to  the  QBot  using  a  Wi-Fi  link.  The  embedded  QBot  computer  then  compiles  the 
source  code  using  GCC.  The  QBot  can  the  execute  the  compiled  code  in  Real-Time  and  can  communicate 
with  other  QuaRC  targets  using  Wi-Fi.  Its  onboard  computer  can  be  used  to  process  data  and  control 
actuators.  The  QBot  can  execute  tasks  without  requiring  a  base  station.  Indeed,  controllers,  sensors  data 
processing  and  other  tasks  can  be  executed  on  the  on  board  embedded  computer.  The  QBot  can  also  be 
part  of  a  Real-Time  simulation.  Indeed,  simulations  can  rely  on  the  QBot  hardware  data.  For  instance,  a 
virtual  vehicle  can  follow  the  QBot  using  its  internal  sensors. 

4,1,  Presentation  of  the  QBot 

The  Figure  23  presents  the  QBot.  The  QBot  is  a  Wheeled  Mobile  Robot  provided  by  Quanser  [5]. 


Figure  23:  Presentation  of  the  QBot 
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QBot’s  embedded  eomputer  speeifieations  are  listed  below: 


Computer 

Type 

GumStix  verdex  pro  XL6P  [12] 

Proeessor 

Marvell®  PXA270  with  XSeale^M  @  600  Mhz 

Cores 

1 

Memory 

128  MB  ram,  32  MB  Flash 

Operatin 
g  System 

Linux  2.6.21 

Web  site 

http :  //www .  gumstix .  ne  t/Hardware/ vie  w/Hard  ware 

-Speeifieations/Verdex-Pro- 

Speeilieations/l  12.html 

Table  1:  QBot  eomputer  speeifieations 


The  QBot  has  the  following  hardware  on  board: 

•  5  IR  Sensors 

•  Battery  Capaeity  Reading  from  the  HIL  Read  Write  Bloek 

•  X- Y -Z  Magnetometers 

•  3  Sonar 

•  7  Analog  Inputs 

•  7  Digital  I/O 

•  8  PWM  Outputs 

•  22  5V  outputs 

•  23  ground 

•  1  Webeam 

•  I  Wi-Fi  interfaee  (802.11) 

•  3  Bumper  Sensors 

•  3  Wheel  drop  sensors 

•  1  Wall  sensor 

•  4  Cliff  sensors 

•  1  Omnidireetional;  Ir  Reeeiver 

•  Power  Button 

•  Play  Button 

•  Advanee  Button 

•  Battery  Voltage,  Battery  Current,  Battery  Temperature,  Battery  Charge  and  Battery  Capaeity  sensor 

•  Veloeity  and  Radius  sensor 

•  Roomba  drive  (2  motors  for  wheels) 

•  1  Speaker 

For  more  information  about  the  QBot  hardware  and  QBot  bloeks,  refer  to  the  QuaRC  iRobot 
doeumentation  provided  with  the  purehase  of  the  QBot. 
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4,2,  Visual  Feedback  Camera  System  and  Flardware  Setup 

QBot  models  have  been  developed  and  tested  at  the  DRDC  Valcartier  hardware  in  the  loop  laboratory. 
This  laboratory  composed  of  a  QuaRC  computer,  a  X-Plane  computer  and  an  OptiTrack  infrared  camera 
tracking  system.  The  QuaRC  computer  (APSEPORCOOP)  is  used  as  a  base  station  for  the  QBot  and  for 
Real-Time  simulation  purposes.  The  X-Plane  computer  (APSERTCLUSTER)  executes  X-Plane  8.4  [4] 
and  display  simulations  results  in  Real-Time  in  a  three  dimensional  environment.  The  OptiTrack  system  is 
composed  of  7  OptiTrack  VlOO  infrared  cameras  [2]  connected  to  the  computer  APMVSWATOILAB  via 
USB.  The  OptiTrack  Tracking  Tools  software  [2]  is  executed  on  APMVSWATOILAB  in  order  to  process 
visual  data.  This  infrared  camera  system  is  used  to  measure  the  trackable’s  position  and  orientation  in 
Real-Time  with  a  refresh  rate  of  100  Flz.  Trackable’s  are  objects  formed  by  infrared  reflectors.  As  you 
can  see  on  the  Figure  24,  infrared  reflectors  (white  balls  mounted  on  wooden  sticks)  has  been  mounted  on 
a  QBot  in  order  to  be  able  to  track  it  in  Real-Time  with  the  OptiTrack  system.  The  Tracking  Tools 
software  sends  the  QBot’s  position  and  orientation  to  a  software  called  VRPN  [3]  (Virtual-Reality 
Peripheral  Network)  Streamer  (Also  executed  on  the  APMVSWATOILAB).  This  software  will  send  the 
QBot’s  position  and  orientation  to  the  QuaRC  computer  via  an  Ethemet/UDP  link.  The  QuaRC  computer 
then  relays  the  visual  feedback  to  the  QBot’s  on  board  computer  via  a  Wi-Fi  link.  The  Figure  26  presents 
a  block  diagram  of  the  hardware  setup  used  to  control  one  QBot  using  visual  feedback.  One  can  see  the 
OptiTrack  system  as  a  local  indoor  GPS. 

In  order  to  use  the  OptiTrack  system,  refer  to  the  Annex  4:  Experimental  Setup  Quick  Start  Guide. 

For  complete  computer  specifications  (Table  11,  Table  12  and  Table  13),  refer  to  the  Annex  1: 
Presentation  of  the  Hardware. 


Figure  24:  QBot  with  mounted  Infrared  Reflectors 


36 


4.2.1.  VRPN  UDP  Streamer 


The  VRPN  [3]  UDP  Streamer  is  a  software  that  is  used  to  transfer  visual  data  from  the  Tracking  Tools 
software  [13]  to  the  QuaRC  computer  using  an  Ethemet/UDP  link.  The  Tracking  Tools  software  sends  the 
QBot  position  and  orientation  to  the  VRPN  Streamer  using  the  VRPN  port  #3883.  The  VRPN  streamer 
then  sends  the  QBot’s  position  and  orientation  to  the  QuaRC  computer  using  an  Ethemet/UDP  link.  The 
QuaRC  computer  will  then  relay  visual  feedback  to  the  QBot  using  a  Wi-Fi  link.  The  QBot  will  then  use 
the  visual  feedback  to  follow  the  commanded  trajectory. 

The  Tracking  Tools  software  and  the  VRPN  Streamer  are  both  executed  on  the  computer  called 
APMVSWATOILAB. 

In  order  to  use  the  OptiTrack  system  and  the  VRPN  Streamer,  refer  to  the  Annex  4:  Experimental  Setup 
Quick  Start  Guide. 

Note  that  the  VRPN  Streamer  executable  and  the  C-i-i-  source  code  have  been  delivered  to  the  DRDC- 
Valcartier  Precision  Weapons  section. 


37 


4.2. 1.1. 


QuaRC  UDP  Receiver 


Receiving  UDP  packets  using  QuaRC  communication  blocks  is  very  useful.  It  allows  QuaRC  models  to 
communication  with  non  QuaRC  targets.  Indeed,  the  QuaRC  UDP  receiver  is  used  to  receive  visual  data 
from  the  VRPN  Streamer. 

To  receive  an  UDP  packet  on  the  QuaRC  computer,  QuaRC  intermediate  server  communication  blocks 
can  be  used.  In  the  Stream  answer  block,  udp://131. 132. 57. 12:19000  (udp  is  the  communication  protocol, 
131.132.57.12  is  the  IP  address  of  the  QuaRC  computer  and  19000  is  the  port  on  which  the  computer 
receives  the  message).  The  Figure  25  presents  the  CamUDP  Simulink  model.  As  you  can  see  on  the 
Figure  25,  the  stream  write  error  is  left  unconnected  because  there  is  no  need  to  send  data  to  the  VRPN 
UDP  Streamer.  You  can  also  see  on  the  Figure  25  the  output  FPS  (Frame  per  Second).  This  is  a  measure 
of  the  mean  refresh  rate  received  from  cameras.  The  FPS  information  can  be  used  to  verify  that  visual 
data  is  received  on  the  QuaRC  computer. 

The  CamUDP  Simulink  model  has  been  delivered  to  the  Precision  Weapons  section  of  DRDC  Valcartier. 


B  CamLIDP/Cameras/Serverl  *  ' 

File  Edit  View  Simulation  Format  Tools 

QuaRC  Help 

□  H  a  p : 
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J  1®  ■  0 

$  H  SOS 

Figure  25:  QuaRC  UDP  receiver 
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4,3.  QuaRC  QBot:  Unicycle  on  QbotFollowTrajectory  Cameras  direct  drive  model 

This  model  allows  the  QBot  to  follow  a  speeifie  trajeetory  using  eamera  feedbaek  (position  and 
orientation,  the  QBot  speed  is  estimated  using  the  time  derivative  of  the  QBot’s  position  on  board  the 
QBot’s  eomputer).  The  low  level  position  eontroller  is  a  feedbaek  linearization  eontroller  [9]  also 
exeeuted  on  board  the  QBot’s  eomputer.  The  trajeetory  eommanded  to  the  QBot  is  a  2  dimensional 
trajeetory  (X  -  Y  trajeetory).  Note  that  Simulink  models  are  exeeuted  at  a  period  of  0.01  s  on  both  QBot 
and  the  QuaRC  eomputer  and  that  the  Simulink  bloek  that  eontrols  QBot’s  wheels  is  exeeuted  at  a  period 
of  0.03  s. 

Note  that  Simulink  models  developed  for  this  experimentation  has  been  delivered  to  the  DRDC-Valeartier 
preeision  weapons  section. 

4.3.1,  Objectives 

The  objectives  of  that  model  are: 

•  Determining  the  perfonnance  of  the  feedback  linearization  (controller  developed  for  the  unicycle 
model)  [9] 

•  Determine  the  position  error  on  the  QBot  when  following  a  trajectory. 

•  Use  the  OptiTrack  Infrared  Camera  system  to  obtain  the  QBot’s  position  in  real-time  and  close  the  low- 
level  controller’s  loop 

4.3.2.  Block  Diagram 

As  you  can  see,  the  OptiTrack  infrared  camera  system  is  used  to  measure  the  QBot’s  position  and 
orientation  in  Real-Time.  This  information  is  then  sent  to  the  QuaRC  computer  (on  the  CamUDP  model). 
The  QuaRC  computer  then  relays  this  information  and  the  requested  trajectory  to  the  QBot  using  a 
wireless  link.  The  QBot’s  embedded  computer  executes  the  feedback  linearization  controller  [9]  in  order 
to  follow  the  commanded  trajectory. 


For  more  information  on  the  hardware,  see  the  Annex  1 :  Presentation  of  the  Hardware. 
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Figure  26:  QBot  follows  trajectory  Overall  Block  diagram 
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4.3.3.  QBot’s  actuators  and  control 


The  Figure  27  presents  QBot  actuators;  left  and  right  wheels.  Note  that  the  front  wheel  is  not  motorized. 
Left  and  Right  wheels  angular  velocity  ( and  G)^ )  can  be  controlled  individually.  Wheels  have  a  radius 

r  =  0.035  m.  The  distance  between  wheels  d  =  0.262  m  (center  to  center).  The  maximum  wheel  angular 
velocity  is  14.2857  rad/s  for  both  motorized  wheel. 


Since  the  feedback  linearization  controller  [9]  outputs  velocity  and  theta  commands  and  the  QBot  can  be 
controlled  by  differential  wheels  control,  a  Simulink  block  has  been  designed  to  convert  velocity  and 
angle  command  to  left  and  right  wheels  angular  velocity  commands: 


CO, 


dcOf. 

dco^ 


left  wheel  angular  velocity 
right  wheel  angular  velocity 


Where  Vc  is  the  commanded  speed  output  from  the  feedback  linearization  controller.  The  QBot 
commanded  angular  velocity  CO^  is  calculated  from  the  commanded  angle  output  of  the  feedback 

linearization  controller  ^^and  the  actual  QBot’s  angled.  Ts  is  Simulink  block  that  controls  wheels 
angular  velocity:  Ts  =  0.03  s. 

-^c-0 
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4.3.3. 1. 


Trajectory  of  the  QBot  and  Initial  Positions 


The  trajectory  commanded  to  the  QBot  is  a  2  dimensional  trajectory  (X  -  Y  trajectory).  The  trajectory  is 
generated  as  follow: 

x{t)  =  0.04^ 
y{t)  =  0.75 

60 

Where:  x(t)  (meter)  is  the  position  on  the  X  axis  ,  y(t)  (meter)  is  the  position  on  the  Y  axis  and  t  is  the 
simulation  time  (second). 
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43.3.2. 


Plots 


The  Figure  28  shows  the  eommanded  and  the  aetual  trajeetories  of  the  QBot  on  the  X-Y  plane.  The  red 
line  represents  the  eommanded  X  trajeetory  and  the  blaek  line  represents  the  QBot’s  trajeetory. 

The  Figure  29  presents  the  QBot  X  trajeetory  error,  the  Y  trajeetory  error  and  the  total  distanee  error  from 
the  eommanded  trajeetory  versus  time.  In  the  transition  state,  the  QBot  has  a  position  error  of  5  em  from 
the  eommanded  trajeetory.  In  steady  state,  the  QBot  has  a  position  error  of  2  em.  Note  that  the  closed  loop 

runs  at  a  period  of  0.0 1  s  except  differential  wheel  commands  ( and  )  that  are  executed  at  a  period  of 
0.03  s.  Note  also  that  the  QBot  model  and  dynamic  has  been  approximated  to  a  simple  unicycle[7]  model 
for  the  feedback  linearizing  controller  design  and  that  performances  are  still  satisfactory. 


Figure  28:  X  and  Y  position  versus  Requested  X  and  Y  (m) 
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Figure  29:  Distance  of  the  QBot  from  the  commanded  trajectory  (m) 
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5.  Comparison  Between  QuaRC  and  RT-Lab  simulation  results 

This  section  will  present  a  comparison  between  QuaRC  and  RT-Lab.  Both  software  products  allow 
developing  Real-Time  distributed  simulations.  Simulation  models  are  developed  using  Matlab/Simubnk 
and  then  converted  to  C++  source  code  using  Matlab/Real-Time  Workshop.  Source  code  is  then  compiled 
and  executed  in  Real-Time.  In  addition,  both  products  allow  separating  models  in  order  to  distribute 
computation  tasks  on  more  than  one  computer. 

It  is  important  to  note  that  both  software  products  can  be  used  to  include  hardware  to  simulations  such  as 
Analog  to  Digital  converters,  Digital  to  Analog  converters,  embedded  processors  and  more. 


5.1.  RT-Lab  and  QuaRC  QuadRotor  validity  test  models 

The  RT-Lab  QuadRotor  validity  test  model  and  the  QuaRC  QuadRotor  validity  test  model  have  been  used 
to  compare  simulation  results  obtained  with  QuaRC.  These  models  have  been  delivered  to  the  DRDC- 
Valcartier  Precision  Weapon  section. 

These  models  present  six  QuadRotor  executing  a  V-Shape  formation  flight.  The  user  can  control  the 
leader’s  velocity,  heading  and  altitude  using  a  joystick.  Followers  will  attempt  to  follow  the  leader  and 
maintain  the  formation’s  geometry.  In  these  simulations,  the  leader,  UAVs  2  and  5  are  executed  on  the 
first  target  and  UAVs  1,3  and  4  are  executed  on  the  second  target.  The  user  can  trigger  an  abrupt  fault  on 
the  UAV  2  at  any  simulation  moment.  The  UAV  5  can  detect  abrupt  faults  that  occur  on  the  UAV  2  using 
the  DAFD  [10]  and  recover  by  following  the  leader  instead  of  following  the  UAV  2.  QuadRotor’s  low 
level  controller  is  the  feedback  linearization  controller  [9]  and  the  formation  geometry  is  preserved  by 
means  of  the  formation  controller  detailed  in  [11].  Simulation  results  are  displayed  on  X-Plane  8.4  [4] 
which  is  executed  on  the  computer  called  APSERTVIEW. 

Note  that  these  simulations  are  based  on  the  QuadRotor  model  [8]. 


5.1.1.  Objectives 

The  objectives  of  that  model  were: 

•  Explore  and  understand  how  to  distribute  models  using  QuaRC. 

•  Compare  simulation  results  obtained  with  RT-Lab,  QuaRC  and  a  regular  simulation 

•  Display  the  simulation  results  in  real-time  on  X-Plane 
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5.1.2,  Block  Diagram 


Figure  30  presents  the  block  diagram  of  the  distributed  QuaRC  QuadRotor  simulation.  Note  that  the 
topology  of  the  formation  is  a  V-Shape  formation  as  shown  on  Figure  32.  The  simulation  uses  3  Real- 
Time  targets.  The  model  named  Console  has  the  task  to  generate  a  trajectory  from  the  joystick  command, 
allow  the  user  to  trigger  a  fault  on  the  UAV  2  and  send  simulation  results  in  Real-Time  to  X-Plane[4]. 
The  leader,  UAVs  2  and  5  are  simulated  on  the  model  Target  1.  UAVs  1,3  and  4  are  simulated  on  the 
model  Target  2.  The  computer  named  APSEQUANSER  is  executing  the  model  Target  1  and  the  computer 
named  APSENLECHEVI  is  executing  the  console  and  the  Target  2  model.  The  console  model  sends 
simulation  results  in  Real-Time  to  the  computer  APSERTVIEW  using  an  Ethemet/UDP  link.  This 
computer  displays  simulation  results  using  the  three  dimensional  viewer  X-Plane  8.4  [4]. 

For  more  information  on  the  hardware,  see  the  Annex  1:  Presentation  of  the  Flardware.  (See  Table  8, 
Table  9  and  Table  10). 
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Figure  30:  QuaRC  Distributed  QuadRotor  simulation 
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The  Figure  31  presents  the  bloek  diagram  of  the  distributed  RT-Lab  QuadRotor  simulation.  Note  that  the 
topology  of  the  formation  is  a  V-Shape  formation  as  shown  on  the  Figure  32.  The  simulation  uses  2  Real- 
Time  targets.  The  model  named  se  eonsole  (Exeeuted  on  APSERTVIEW)  has  the  task  to  generate  a 
trajeetory  from  the  joystiek  eommand,  allow  the  user  to  trigger  a  fault  on  the  UAV  2.  The  leader,  UAVs  2 
and  5  are  simulated  on  the  Target  1.  UAVs  1,3  and  4  are  simulated  on  Target  2.  The  eomputer  named 
APSERTVIEW  is  used  to  display  simulation  results  in  Real-Time  on  X-Plane  8.4  [4]. 


For  more  information  on  the  hardware,  see  the  Annex  1:  Presentation  of  the  Hardware.  (See  Table  4, 
Table  5,  Table  6  and  Table  7). 
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Figure  31:  RT-Lab  Distributed  QuadRotor  simulation 
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Figure  32:  QuadRotor  Formation  topology  (lines  indieate  information  flow) 
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5.1.3.  Results 


Simulations  have  been  done  using  the  original  Simulink  QuadRotor  model  [8],  the  QuaRC  distributed 
QuadRotor  model  and  the  RT-Lab  distributed  model.  Note  that  on  both  QuaRC  and  RT-Lab  models, 
UAVs  0,  2  and  5  are  executed  on  the  first  target  and  UAVs  1,3  and  5  are  executed  on  a  second  target.  On 
the  Figure  33  the  X-Y  trajectory  of  the  UAV  4  is  plotted  for  the  regular  Simulink  Simulation  (blue  dashed 
line),  the  QuaRC  distributed  simulation  (green  dashed  line)  and  the  RT-Lab  distributed  simulation  (red 
line). 
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Figure  33:  Simulation  results  for  the  UAV  4  in  regular  simulation,  RT-Lab  simulation  and  QuaRC 
Simulation 
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On  the  Figure  34  the  X-Y  trajeetory  of  the  UAV  5  is  plotted  for  the  regular  Simulink  Simulation  (blue 
dashed  line),  the  QuaRC  distributed  simulation  (green  dashed  line)  and  the  RT-Lab  distributed  simulation 
(red  line).  Note  that  the  trajectory  of  the  UAV  5  has  an  abrupt  change  around  X  =  100  m  and  Y  =  40  m.  It 
is  due  to  the  fact  that  the  UAV  2  had  a  fault  at  this  moment  and  that  the  UAV  5  has  detected  it  and  then 
starts  to  follow  the  leader  instead  of  following  the  UAV  2. 


Figure  34:  Simulation  results  for  the  UAV  5  in  regular  simulation,  RT-Lab  simulation  and  QuaRC 
Simulation 


As  you  can  see,  on  QuaRC,  plots  have  been  translated  to  the  left  compared  to  curves  from  the  regular 
model  and  curves  from  the  RT-Lab  simulation.  It  can  be  explained  by  the  way  models  are  started  using 
QuaRC.  In  QuaRC,  the  simulation  is  split  in  3  different  models.  To  begin  the  simulation,  models  must  be 
started  sequentially  causing  a  delay  between  the  moment  models  are  started  and  the  moment  models  are 
enabled  (See  the  Annex  7: Synchronizing  QuaRC  Models).  This  delay  affects  the  way  the  trajectory  is 
generated  and  thus  slightly  affecting  simulation  results. 
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6.  Major  Differences  Between  QuaRC  and  RT-Lab 


This  section  presents  a  comparison  chart  between  QuaRC  and  RT-Lab.  Both  software  products  allow 
developing  a  simulation  model  that  can  be  executed  in  real-time.  Model  are  developed  using 
Matlab/Simulink,  they  are  then  converted  to  C++  and  compiled  using  the  Real-Time-Workshop  compiler. 
Both  products  allow  the  user  to  distribute  the  computation  task  over  multiple  computers  and  cores. 


6.1.  Major  differences  between  QuaRC  and  RT-Lab 
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the  target 

(Reset 
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Initial  state 
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Table  2:  Major  differences  between  QuaRC  and  RT-Lab 
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your  model 
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Table  3:  Major  differences  between  QuaRC  and  RT-Lab 
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6.2,  QuaRC  Strong  Points 

•  QuaRC  has  a  very  complete  communication  block  set  that  allows  communicating  with  non  QuaRC 
targets.  For  example,  QuaRC  communication  blocks  are  used  to  receive  data  from  the  OptiTrack 
computer  on  an  Ethemet/UDP  link. 

•  Integrating  hardware  with  QuaRC  is  made  easy  with  the  QuaRC  Communications  Library  which  is 
available  in  the  Simulink  library  browser. 

•  Quanser  also  provides  hardware  boards  or  robots  (ground,  air)  that  are  QuaRC  compatible.  Flardware 
can  be  integrated  to  a  QuaRC  FIIL  system  very  quickly. 

•  Targets  can  be  windows  targets,  linux  arm  targets,  linux_x86,  and  qnx_x86.  QNX 

•  Constants  can  be  changed  during  the  real-time  execution  on  any  target 


6,3.  QuaRC  Weak  Points 

•  Using  Model  and  Target  URI  can  be  confusing 

•  Flandling  communications  can  be  confusing 

•  A  model  that  is  not  properly  configured  can  crash  Matlab  when  executed 

•  Computation  timings  may  be  hard  to  obtain  when  using  windows  targets 


6,4,  RT-Lab  Strong  Points 

•  Flandling  communications  is  user  friendly 

•  Handling  targets  is  user  friendly 

•  Building  and  loading  is  user  friendly 

•  Obtaining  Computation  timings  is  very  easy 

•  RT-Lab  provides  hardware  boards  that  allow  to  design  a  HIL  system 


6,5.  RT-Lab  Weak  Points 

•  Communication  blocks  do  not  allow  exchanging  data  with  non  RT-Lab  targets  using  the  Ethernet  port, 
an  S-Function  must  be  programmed  in  order  to  do  so. 

•  Constants  can’t  be  changed  on  real-time  targets,  but  it  is  indeed  possible  to  initialize  constants  in  the 
RT-Lab  console  and  change  them  without  needing  to  recompile 

•  Real-Time  targets  can’t  be  widows  target 
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7.  Conclusion 


This  report  presented  real-time  formation  flight  simulation  models.  Formations  presented  are  composed  of 
ALTAVs,  unicycles  and  quadrotors.  Formation  geometries  used  for  these  models  are  V-Shape  and  String- 
Shape  types.  Simulation  models  include  vehicles  dynamics,  low-level  controller  and  high-level  formation 
controller.  It  was  demonstrated  through  simulations  that  homogenous  formations  remained  stable.  It  was 
also  demonstrated  that  both  formation  controller  (leader-follower  type)  and  low-level  controller  (feedback 
linearization  controller)  can  be  ported  to  several  aerial  platforms  and  executed  in  real-time,  and  thus  are 
realizable.  Simulation  models  were  developed  using  Matlab/Simulink  then  ported  to  QuaRC  and  RT-Lab 
compliant  models.  Both  QuaRC  and  RT-Lab  environments  allow  compiling,  distributing  and  executing 
Simulink  models  in  real-time. 

The  feedback  linearization  controller  was  implemented  onboard  a  wheeled  mobile  robot  (Quanser  QBot) 
embedded  processor.  It  was  shown  that  this  low-level  controller  can  be  executed  on  a  computer  with 
limited  computational  capabilities  and  memory,  and  yet,  it  was  demonstrated  that  the  QBot  can  follow  an 
X-Y  trajectory  with  satisfactory  performances.  The  robot’s  position  is  measured  using  an  infrared  camera 
setup  and  the  position  information  is  sent  to  the  robot’s  embedded  computer  where  the  low-level 
controller  is  executed.  Note  that  the  visual  data  is  sent  from  the  base  station  to  the  QBot  using  a  wireless 
link.  This  experiment  showed  that  the  controller  was  robust  to  measurement  noise  on  the  position,  on  the 
heading  and  on  the  speed  estimation. 

QuaRC  and  RT-Lab  were  compared.  Both  software  solutions  enable  to  develop  models  using 
Matlab/Simulink,  compile,  distribute  and  execute  models  in  Real-Time.  Simulink  models  are 
automatically  converted  to  C++  code,  which  is  then  compiled  for  specified  Targets.  In  general,  RT-Lab  is 
easier  to  use  than  QuaRC,  although  it  provides  less  flexibility  than  QuaRC.  Indeed,  QuaRC  provides 
several  options  such  as  the  possibility  to  choose  and  configure  communication  options. 

Finally,  this  report  presented  quick  start  guides  for  the  RT-Lab  and  QuaRC  setups  that  are  used  to  execute 
distributed  real-time  simulations  and  the  QuaRC  hardware-In-the-loop  setup  that  is  used  to  perform 
experiments  using  wheeled  mobiles  robots,  QuaRC  and  the  infrared  tracking  camera  system. 

Future  work  will  present  mixed  simulation  models  and  wheeled  mobile  robot  experiments.  In  other  words, 
the  development  of  an  experiment  including  simulated  vehicles  and  real  wheeled  mobile  robots  is 
planned.  In  addition,  the  development  of  a  formation  composed  entirely  of  wheeled  mobile  robots  is  also 
planned.  Furthermore,  there  will  be  experiments  on  decentralized  fault,  failure  and  anomaly  detection. 
Ultimately,  the  formation  will  use  onboard  sensors  to  navigate  and  thus  removing  the  dependency  on  the 
infrared  camera  system. 

The  formation  control  can  have  multiple  civil  and  military  applications  such  as  automated  aerial  refueling, 
coordinated  bombing,  territorial  surveillance,  multi-vehicle  heavy  lift.  Formation  control  can  also  provide 
unmanned  support  to  manned  vehicles  for  surveillance  or  combat  missions. 
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Appendix 

REF  1 :  Quanser  QBot  User  Manual 

The  QBot  User  Manual  is  provided  with  the  purehase  of  the  QBot 

REF  2:  OptiTraek  Website 
http://www.naturalpoint.eom/optitraek/  [2] 

REF  3 :  Natural  Point  Rigid  Body  Toolkit 

http://www.naturalpoint.eom/optitraek/support/downloads-arehive.html  [2] 

REF  4:  Natural  Point,  Point  Cloud  Calibration  Tools 
http://www.naturalpoint.eom/optitraek/support/downloads-arehive.html  [2] 

REF  5:  Natural  Point  Traeking  Tools 

http://www.naturalpoint.eom/optitraek/support/downloads.html#software  [2] 

REF  6:  Natural  Point  Tutorial  Videos 

http://www.naturalpoint.eom/optitraek/produets/videos.html#tt  [2] 

REF  7:  VRPN  UDP  Streamer 

The  VRPN  UDP  Streamer  souree  eode  and  visual  studio  projeet  has  been  delivered  to  DRDC-Valeartier 
Preeision  Weapons  Seetion. 

REF  8:  QuaRC  QBot:  Unieycle  on  QbotFollowTrajeetory  Cameras  direet  drive 
This  model  has  been  delivered  to  DRDC-Valeartier  Preeision  Weapons  Seetion. 

REF  9:  QuaRC  Windows:  QuadRotor_Fault_Deteet_Joystiek_3onTargetl_3onTarget2 
This  model  has  been  delivered  to  DRDC-Valeartier  Preeision  Weapons  Seetion. 

REF  10:  RT-Lab:AFG_summer2007joystiek 
This  model  has  been  delivered  to  DRDC-Valeartier  Preeision  Weapons  Seetion. 

REF  11:  RT-Lab:AFG_summer2007joystiek2CPUs 
This  model  has  been  delivered  to  DRDC-Valeartier  Preeision  Weapons  Seetion. 

REF  12:  RT-Lab:AFG_summer2007joystiekFlWsynehro 

This  model  has  been  delivered  to  DRDC-Valeartier  Preeision  Weapons  Seetion. 

REF  13:  RT-Lab:ALTAVeonvoyTeamFDRSummer2007(DAFD)FlWSynehro 
This  model  has  been  delivered  to  DRDC-Valeartier  Preeision  Weapons  Seetion. 

REF  14:  RT-Lab:ALTAVeonvoyTeamFDRSummer2007joystiek(DAFD) 

This  model  has  been  delivered  to  DRDC-Valeartier  Preeision  Weapons  Seetion. 

REF  15:  RT-Lab:  QuadRotor  validity  test 

This  model  has  been  delivered  to  DRDC-Valeartier  Preeision  Weapons  Seetion. 
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Annex  1 :  Presentation  of  the  Hardware 


This  annex  presents  computers  that  compose  the  RT-Lab  distributed  simulation  setup,  the  QuaRC  distributed 
simulation  setup  and  the  QuaRC  Hardware  In  the  Loop  setup. 


1.  RT-Lab  Setup 

The  Figure  35  presents  the  RT-Lab  setup  bloek  diagram.  This  setup  is  used  to  distribute  Real-Time 
simulations  using  RT-Lab.  This  setup  is  composed  of  one  non  Real-Time  Target  (APSEQUANSER 
executing  Windows  XP  OS)  and  two  Real-Time  Targets  (Target  1  and  Target  2  executing  RedHawk 
Linux  OS).  The  non  Real-Time  Target  allows  the  user  to  visualize  simulation  results  and  modify 
simulation  parameters  during  the  model’s  execution.  RedHawk  targets  execute  simulation  models  in  Real- 
Time.  Note  that  RedHawk  targets  can  be  synchronized  via  software  (using  Ethemet/UDP  or  FireWire)  or 
via  an  hardware  synchronization  board.  A  fourth  computer  (APSERTVIEW)  executes  X-Plane  8.4.  This 
software  displays  simulations  results  in  Real-Time  in  a  3  dimensional  environment  in  Real-Time. 


APSEQUANSER  (Windows  OS) 


Target  1  (RedHawk  Linux  OS) 


Target  1  (RedHawk  Linux  OS) 


Figure  35:  RT-Lab  Hardware  Setup 

1.1.  RT-Lab  Windows  Target  (Non  Real  Time  Target) 


Computer  Name 

APSEQUANSER 

Computer  Type 

DELL  OPTIPLEX  GX280 

Processor 

Pentium®  4  3.00GHz 

Cores 

1 

Memory 

1.5  GB  Ram 

Video  Card 

Intel®  82915G/GV/910GL 

Express 

Operating  System 

Microsoft  Windows  XP 

Professional  SP3 

Matlab  Version 

R2007b 

QuaRC  Version 

1.2 

RT-Lab  version 

8.2  beta  4 

Table  4:  APSEQUANSER  computer  specifications 
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1.2.  RT-Lab  RedHawk  Linux  Target  (Real-Time  Target) 


Computer  Name 

Target  1 

Computer  Type 

Dell  Precision  530 

Processor 

Intel  P4/Xeon  Extended 

MCE  2.2  GHz 

Cores 

1 

Memory 

1  GB  Ram 

Operating  System 

RedHawk  Linux  2.3 

Hardware  Synchronization 
card 

National  Instrument  NI-6602 

Table  5:  Target  1  computer  specifications 


Computer  Name 

Target  2 

Computer  Type 

Dell  Precision  530 

Processor 

Intel  P4/Xeon  Extended 

MCE  2.2  GHz 

Cores 

1 

Memory 

1  GB  Ram 

Operating  System 

RedHawk  Linux  2.3 

Hardware  Synchronization 
card 

No 

Table  6:  Target  2  computer  specifications 


1.3.  X-Plane  computer  (Non  RT-Lab  Target) 


Computer  Name 

APSERTVIEW 

Computer  Type 

DELL  XPS  600 

Processor 

Intel  ®  Pentium®  D  CPU 

3.46  GHz 

Cores 

4 

Memory 

2  GB  Ram 

Video  Card 

nVIDIA  GeForce  7900  GTX 

Operating  System 

Microsoft  Windows  XP 

Professional  SP2 

Matlab  Version 

R2007b 

QuaRC  Version 

1.2 

X-Plane  version 

8.4 

Table  7:  APSERTVIEW  computer  specifications 
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2.  QuaRC  Windows  Setup 

The  Figure  36  presents  the  QuaRC  distributed  hardware  setup.  As  you  can  see,  three  Windows  XP 
computer  are  connected  together  using  an  Ethernet  connection.  Each  computer  can  be  used  as  a  target 
and/or  to  build  models.  The  computer  APSERTVIEW  executes  X-Plane  8.4.  X-Plane  is  a  three 
dimensional  viewer  that  displays  simulation  results  in  Real-Time.  Any  QuaRC  target  can  send  data  in 
Real-Time  to  X-Plane  using  an  Ethemet/UDP  link.  QuaRC  models  can  exchange  data  using  an 
Ethemet/TCP  link. 


APSERTVIEW  (Windows  OS) 


APSEQUANSER  (Windows  OS)  APSENLECHEVI  (Windows  OS) 

Figure  36:  QuaRC  Distributed  Simulation  Flardware  Setup 
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Following  tables  presents  QuaRC  computers  specifications. 


Computer  Name 

APSERTVIEW 

Computer  Type 

DELL  XPS  600 

Processor 

Intel  ®  Pentium®  D  CPU 

3.46  GHz 

Cores 

4 

Memory 

2  GB  Ram 

Video  Card 

nVIDIA  GeForce  7900  GTX 

Operating  System 

Microsoft  Windows  XP 

Professional  SP2 

Matlab  Version 

R2007b 

QuaRC  Version 

1.2 

X-Plane  version 

8.4 

Table  8:  APSERTVIEW  computer  specifications 


Computer  Name 

APSENLECHEVI 

Computer  Type 

DELL  Precision  360 

Processor 

Pentium®  4  3 .20GHz 

Cores 

1 

Memory 

1  GB  Ram 

Video  Card 

nVIDIA  Quadro  FX  500/600 

Operating  System 

Microsoft  Windows  XP 

Professional  SP2 

Matlab  Version 

R2007b 

QuaRC  V ersion 

1.2 

Table  9:  APSENLECFIEVI  computer  specifications 


Computer  Name 

APSEQUANSER 

Computer  Type 

DELL  OPTIPLEX  GX280 

Processor 

Pentium®  4  3.00GHz 

Cores 

1 

Memory 

1.5  GB  Ram 

Video  Card 

Intel®  82915G/GV/910GL 

Express 

Operating  System 

Microsoft  Windows  XP 

Professional  SP3 

Matlab  Version 

R2007b 

QuaRC  Version 

1.2 

Table  10:  APSEQUANSER  computer  specifications 
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3.  QuaRC  HIL  setup 


The  Figure  37  presents  the  bloek  diagram  of  the  QuaRC  FilL  setup.  This  setup  is  used  to  exeeute 
Fiardware  In  the  Loop  simulations  and  Wheeled  Mobile  Robot  experiments.  This  setup  is  eomposed  of 
one  QuaRC  eomputer  (APSEPORCOOP),  one  X-Plane  eomputer  [4]  (APSERTCLUSTER),  one 
OptiTraek  eomputer  (APMVSWATOILAB)  and  Wheeled  Mobile  Robots  (QBots).  Note  that  the  QBot 
possesses  an  embedded  eomputer  on  board.  Eaeh  eomputer  ean  exehange  data  using  an  Ethernet  link. 
Indeed,  The  OptiTraek  eomputer  sends  visual  feedbaek  data  to  the  QuaRC  eomputer  using  Ethemet/UDP. 
The  QuaRC  eomputer  sends  simulation  results  to  the  X-Plane  eomputer  using  Ethemet/UDP.  Note  also 
that  the  QuaRC  eomputer  and  the  QBot  ean  exehange  data  using  a  wireless  link  (Wi-Fi). 


QuaRC  Computer  Qbot 


X-Plane  OptiTraek 

Computer  Computer 


Figure  37:  QuaRC  HIL  hardware  speeifieations 
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3.1.  QuaRC  Computer 


This  computer  is  used  to  develop,  compile  and  load  QuaRC  models.  This  computer  can  also  be  used  as  a 
QuaRC  Real-Time  Target  or  processing  base  station  for  Wheeled  Mobile  Robots.  In  fact,  visual  feedback 
is  relayed  by  this  computer  from  the  Camera  feedback  computer  to  QBots. 


Computer  Name 

APSEPORCOOP 

Computer  Type 

DELL  Inspiron  9300 

Processor 

Intel®  Pentium  M  2.00  GHz 

Cores 

2 

Memory 

2  GB  Ram 

Video  Card 

nVIDIA  GeForce  Go  6800 

Operating  System 

Microsoft  Windows  XP 

Professional,  Service  Pack  3 

Matlab  Version 

R2007b 

QuaRC  V ersion 

1.2 

Table  11:  APSEPORCOOP  computer  specifications 


3.2.  Natural  Point  OptiTrack  computer 

This  computer  is  used  to  process  in  real-time  the  infrared  cameras  data  and  extract  the  position  and 
bearing  of  rigid  bodies.  This  computer  is  connected  to  seven  infrared  cameras  (OptiTrack  VlOO).  The 
Tracking  Tools  software  2.0  beta  [2]  is  used  to  process  visual  data. 


Computer  Name 

APMVSWATOILAB 

Computer  Type 

DELL  XPS  720 

Processor 

Intel  coreT"^  2  extreme 

Q6800  @  2.93  GHz 

Cores 

4 

Memory 

3  GB  Ram 

Video  Card 

nVIDIA  GeForce  7300  GS 

Operating  System 

Microsoft  Windows  XP 
media  center.  Service  Pack  2 

Tracking  tools  version 

2.00  Beta 

Infrared  Cameras 

OptiTrack  VlOO 

Table  12:  APMVSWATOILAB  computer  specifications 


3.3.  X-Plane  Computer 
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This  computer  is  used  to  show  the  simulation  results  in  a  3d  environment  called  X-Plane  [4].  X-Plane  is 
used  to  display  up  to  ten  aerial  vehicles  in  a  3D  environment.  Vehicles  position  and  orientation  can  be 
updated  in  Real-Time  during  simulations  or  Wheeled  Mobile  Robot  experiments. 


Computer  Name 

APSERTCLUSTER 

Computer  Type 

Dell  Precision  T5400 

Processor 

Intel®  Xeon®  E5405  @  2.00 

GHz 

Cores 

1 

Memory 

3.25  GBRam 

Video  Card 

nVIDIA  Quadro  NVS  290 

Operating  System 

Microsoft  Windows  XP 

Professional,  Service  Pack  2 

X-Plane  version 

8.4 

Table  13:  APSERTCLUSTER  computer  specifications 


3.4.  QBot  computer 

The  QBot  is  a  Wheeled  Mobile  Robot  that  can  be  programmed  using  Real-Time  Workshop/QuaRC.  This 
robot  has  an  embedded  computer  that  allows  executing  algorithms  on  board.  This  robot  also  possesses  a 
Wi-Fi  interface  that  allows  communicating  with  the  QuaRC  base  station  or  other  QBots. 


The  QBot  has  following  sensors  on  board: 

•  5  IR  Sensors 

•  Battery  Capacity  Reading  from  the  Fill  Read  Write  Block 

•  X- Y -Z  Magnetometers 

•  3  Sonars 

•  7  Analog  Inputs 

•  7  Digital  I/O 

•  8  PWM  Outputs 

•  22  5V  outputs 

•  23  ground 

•  1  Webcam 

•  1  Wi-Fi  interface  (802.11) 

•  3  Bumper  Sensors 

•  3  Wheel  drop  sensors 

•  1  Wall  sensor 

•  4  Cliff  sensors 

•  1  Omnidirectional;  Ir  Receiver 

•  Power  Button 

•  Play  Button 

•  Advance  Button 

•  Battery  Voltage,  Battery  Current,  Battery  Temperature,  Battery  Charge  and  Battery  Capacity  sensor 

•  Velocity  and  Radius  sensor 

•  Roomba  drive  (2  motors  for  wheels) 

•  1  Speaker 


Table  14  presents  the  hardware  specification  of  the  QBot  on  board  computer: 


Computer 

GumStix  verdex  pro  XL6P  [12] 

Type 

63 


Processor 

Marvell®  PXA270  with  XScaleTM  @  600  Mhz 

Cores 

1 

Memory 

128  MB  ram,  32  MB  Flash 

Operatin 
g  System 

Linux  2.6.21 

Web  site 

http :  //www .  gumstix .  net/Hardware/ vie  w/Hard  ware 
-Specifications^  erdex-Pro- 
Specifications/1 12.html 

Table  14:  QBot  computer  specifications 
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Annex  2:  RT-LAB  Quick  Start  Guide 


1.  RT-Lab  Quick  Start  Guide 

RT-Lab  is  a  software  that  allows  to  developing  simulation  models  that  can  be  executed  in  real-time. 
Models  are  developed  using  Matlab/Simulink.  They  can  then  be  converted  to  C++  and  compiled  using  the 
RT-Lab  Real-Time- Workshop  compiler.  RT-Lab  also  offers  to  split  models  into  smaller  models  in  order 
to  distribute  the  computation  task  to  more  than  one  computer  or  more  than  one  computer  core.  Each 
computation  node  (computer  or  core)  will  be  called  a  Target.  For  example,  if  a  computer  has  4  cores,  it  is 
possible  to  execute  4  different  models  (one  on  each  core).  This  computer  can  then  support  4  Targets. 

1.1.  Avai  lab  le  example 

Following  models  are  available  the  DRDC-Valcartier  Precision  Weapon  Section.  These  models  can  be 
used  as  example  to  begin  using  RT-Lab. 

•  RT-Lab:AFG_summer2007joystick 

•  RT-Lab  :AFG_summer2007joystick2CPUs 

•  RT -Lab :  AFG_summer2007joystickFtW  synchro 

•  RT -Lab :  ALTAVconvoyT  eamFDRSummer2007(DAFD)FtW  Synchro 

•  RT-Lab:ALTAVconvoyTeamFDRSummer2007joystick(DAFD) 

•  RT-Lab  QuadRotor  model 
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1.2.  RT-Lab  Main  Control 


The  Figure  38  shows  the  RT-Lab  main  eontrol  panel.  This  panel  allows  eonfiguring  simulation  and 
models  parameters.  In  order  to  eompile  and  exeeute  a  model,  RT-Lab  must  eonneet  to  the  Simulink 
model;  eliek  on  the  Conneet  button  and  seleet  the  desired  model.  Onee  the  model  is  eonneeted,  eliek  on 
eompile.  A  new  window  will  then  open  and  display  eompilation  results.  Onee  models  are  eompiled,  eliek 
on  load  to  send  exeeutables  to  Targets.  Onee  models  are  loaded,  eliek  on  exeeute  to  start  models. 


Figure  38:  RT-Lab  Main  Control  Panel 
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The  Figure  39  presents  RT-Lab  an  example  of  model  distribution  scheme.  Four  Targets  are  presented: 
SC  Console,  SM  Master,  SS  Slavel  and  SS_Slave2.  The  model  called  SC  Console  is  a  Non  Real-Time 
Target  executed  on  windows.  This  Target  is  used  to  give  the  user  an  interface  with  Real-Time  Targets. 
Indeed,  users  can  change  simulation  parameters  in  the  console.  These  changes  will  then  be  sent  to  Real- 
Time  Targets  (Each  Target  besides  the  SC  Console).  SM  Master  is  the  target  that  handles  software 
synchronization  or  hardware  synchronization.  This  Target  can  also  be  used  as  a  calculation  node.  This 
Target  is  mandatory  in  a  Real-Time  RT-Lab  simulation.  SS  Slavel  and  SS_Slave2  are  used  as  calculation 
nodes  and  are  optional  in  RT-Lab  simulations.  However,  these  Targets  can  be  useful  to  distribute 
calculation  tasks. 

Note  that  RT-Lab  models  are  split  as  such: 

Each  Targets  are  defined  in  the  same  Simulink  Model.  Targets  are  subsystems  called  SC_”Something”  for 
the  console,  SM_”Something”  for  the  Master  and  SS_”Something”  for  slaves.  Where  “Something”  is  a 
name  the  user  can  choose. 


Figure  39:RT-Lab  Model  Separation 

For  more  information  about  RT-Lab  or  RT-lab  blocks,  refer  to  the  RT-Lab  help  located  in  the  Matlab 
Help  or  to  the  RT-Lab  Web  site:  http://www.opal-rt.com/ 
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Annex  3 :  QuaRC  documentation 

This  Annex  presents  QuaRC  documentation  and  QuaRC  demos  that  a  new  QuaRC  user  should  explore  to 
learn  QuaRC  basics. 

1 .  Demo  QuaRC 

To  access  the  QuaRC  demo  list,  type  qc  show  demos  in  the  Matlab  console. 

Note  that  to  execute  demos,  simply  choose  a  QuaRC  demo  and  follow  the  instructions. 

The  following  demos  are  recommended  for  new  QuaRC  users: 

•  QuaRC  Sine  and  Scope  Demo  (Only  execute  the  windows  target  demo) 

•  QuaRC  Data  Logging  Demo 

•  QuaRC  Computation  Time  Demo 

•  QuaRC  System  Time  Base  Demo 

•  QuaRC  Basic  Communications  Demo 

•  QuaRC  Intermediate  Communications  Demo 

2.  Demo  QBot 

Type  qc  show  demos  in  Matlab  console  and  execute  the  following  demo: 

•  Running  Models  using  the  QuaRC  GumStix  (Linux  ARM)  Target 

Also  executes  the  QuaRC  QBot  demo  models  delivered  with  the  purchase  of  the  QBot 

•  keyboardcontrol 

•  qbotdrive 

•  qbotcamera 

•  qbotsensors 

Note:  It  is  recommended  to  execute  demos  presented  in  the  section  1  before  these  ones. 

3.  Matlab  help 

For  any  help  concerning  QuaRC  blocks  or  QuaRC  functions,  refer  to  the  Matlab/Simulink  help  under  the 
QuaRC  Target  tab. 

4.  IRobot  user  manual 

It  is  recommended  to  read  the  QuaRC  iRobot  documentation  that  has  been  provided  with  the  purchase  of 
the  QBot. 

5.  Quarc  Installation  Guide 

It  is  recommended  to  read  the  QuaRC  installation  guide  that  has  been  provided  with  the  purchase  of 
QuaRC. 
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Annex  4:  Experimental  Setup  Quiek  Start  Guide 


This  Annex  presents  a  quiek  start  guide  for  executing  wheeled  mobile  robot  experiments  using  the 
QuaRC  Wheeled  Mobile  Robot/Hardware  In  the  Loop  setup.  This  annex  will  present  software  and 
hardware  requirements  and  software  configurations. 

1.  Requirements 

To  be  able  to  operate  the  OptiTrack  +  QuaRC  setup,  one  must  have  the  following  hardware  and  software: 

•  A  QuaRC  computer  with  a  wireless  adapter  and  an  Ethernet  adapter. 

•  Valid  QuaRC  models  with  the  proper  Quarc  init.m  file 

•  1  or  more  QBot 

•  A  Computer  with  OptiTrack  Tracking  Tools 

•  A  version  of  VRPN  Streamer  configured  to  send  data  to  the  IP  address  of  the  QuaRC  computer 

•  Infrared  reflectors 

•  Calibration  Wand 

•  A  computer  with  X-Plane  (Required  only  to  visualize  simulation  results  in  real-time) 


One  would  follow  these  steps: 

•  Log  on  computers 

•  Start  X-Plane 

•  Calibrate  the  camera  setup  (Or  open  an  existing  one) 

•  Set  the  ground  plane  in  the  Tracking  Tools  Software  (Only  after  a  calibration) 

•  Place  Infrared  Reflectors  on  QBots  (or  the  objects  to  track) 

•  Create  Trackables  in  the  Tracking  Tools  Software  (Or  Open  an  existing  one) 

•  Configure  the  Tracking  Tools  Software  to  send  Trackables  data  to  a  VRPN  port 

•  Configure  the  VRPN  Streamer  to  send  the  data  to  the  QuaRC  Computer 

•  Open  QBots  and  place  them  in  the  playground 

•  Verify  that  the  QuaRC  computer  receives  the  camera  data. 

•  Open  Models  and  Quarc  init.m 

•  Enable  the  wireless  adapter  of  the  QuaRC  Computer 

•  Verify  that  QBots  are  connected  to  the  QuaRC  Computer 

•  Open  remote  consoles  on  QBots  (Facultative) 

•  Launch  Quarc  init.m 
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2.  Additional  documentation 

There  is  also  a  video  based  on  this  doeument  that  is  available.  The  video  shows  how  to  start  a  simulation 
using  the  eamera  setup  and  the  QuaRC  setup.  It  also  shows  how  to  ealibrate  and  ereate  Traekables  with 
the  OptiTraek  Traeking  tools  software. 

3.  Log  on  computers 

Make  sure  that  the  Ethernet  adapter  of  eaeh  eomputer  is  eonneeted  to  the  Valeartier  network,  then  log  on 
using  your  personal  login  name  and  password.  One  would  log  on  the  QuaRC  eomputer,  the  viewer 
eomputer  (X-Plane  eomputer)  and  the  OptiTraek  eamera  eomputer. 


4.  Start  X-Plane 

Launeh  X-Plane  on  the  X-Plane  eomputer. 


5.  Calibrate  the  camera  setup 

In  order  to  ealibrate,  refer  to  the  Traeking  Tools  video  tutorial  seetion: 
http://www.naturalpoint.eom/optitraek/produets/traeking-tools/videos.html. 

One  ean  then  save  the  ealibration  by  elieking  on  File->Save  Calibration.  One  eould  open  an  existing 
ealibration  file  and  start  using  the  setup  right  away.  Note  that  a  ealibration  file  also  saves  the  ground 
plane. 


6.  Set  the  ground  plane 

In  order  to  set  the  ground  plane  properly,  refer  to  the  Traeking  Tools  video  tutorial  seetion: 
http://www.naturalpoint.eom/optitraek/produets/traeking-tools/videos.html. 

Note  that  eaeh  model  has  been  developed  to  use  only  the  X  and  Y  axis  and  ignore  the  Z  axis  (elevation). 
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7 .  Place  Infrared  Reflectors  on  QBots 

The  Figure  40  presents  a  QBot  on  which  infrared  reflectors  are  installed  (white  glowing  balls  mounted  on 
wooden  sticks).  It  is  recommended  to  respect  following  tips  when  placing  reflectors: 

Place  at  least  4  markers  on  QBots  to  ensure  that  the  Tracking  Tools  Software  will  be  able  to  estimate  the 
position  and  the  angle  of  the  QBot  properly.  In  order  to  do  so,  one  must  not  place  markers  in  a  way  that  a 
plan  is  formed  by  the  marker  set.  The  reason  this  constraint  is  that  2  possible  angles  can  now  be  estimated 
from  the  camera  system.  When  placing  markers  on  more  than  one  QBot,  make  sure  that  the  form  created 
by  these  marker  is  not  too  similar  to  others  because  the  Tracking  Tools  Software  will  have  difficulty 
differencing  them. 
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8.  Create  Trackables  in  the  Tracking  Tools  Software 


In  order  to  create  a  trackable,  refer  to  the  Tracking  Tools  video  tutorial  section: 
http://www.naturalpoint.com/optitrack/products/tracking-tools/videos.html.  One  can  then  save  Trackables 
by  clicking  on  File->Save  Trackables.  One  could  open  an  existing  trackable  file  and  jump  to  the  next  step. 

As  you  can  see  on  the  Figure  41,  markers  corresponding  to  the  QBot  are  displayed  in  the  Tracking  Tools 
Main  window.  On  the  Figure  42,  you  can  see  that  the  markers  has  been  selected  (hold  the  left  mouse 
button  and  cover  the  markers  area,  then  release  it).  With  the  right  mouse  button,  click  on  one  of  the 
selected  markers  and  click  on  create  trackable.  One  the  Figure  43,  one  can  see  that  the  trackable  has  been 
created.  On  the  right  pane,  there  are  trackable  options.  One  can  change  Trackables’  name.  Changing  the 
name  of  the  trackable  is  required  to  send  data  to  the  VRPN  Streamer  since  the  current  VRPN  Streamer  is 
configured  to  accept  trackable  with  the  following  names:  Tracker  and  Tracker2. 


«  I « • 


Figure  41:  QBot  Markers 
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Figure  42:  Create  Traekable  from  visible  markers 


Figure  43:  Traekable  ereated 
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9.  Configure  Tracking  Tools  Software  to  send  Trackable  data 

In  order  to  send  traekable  data  to  the  QuaRC  eomputer,  one  must  eonfigure  the  Tracking  Tools  Software 
to  send  trackable  data  to  the  VRPN  Streamer,  and  then  the  VRPN  Streamer  will  send  the  Data  to  the 
QuaRC  Computer.  The  VRPN  Streamer  is  a  software  running  on  the  OptiTrack  Computer  that  retransmits 
trackable  data  from  the  Tracking  Tools  Software  to  the  QuaRC  Computer. 

To  send  data  to  the  VRPN  Streamer,  one  would  need  to  change  the  names  of  the  tracker  to  valid  names. 
The  VRPN  Streamer  is  configured  to  accept  2  Trackable:  Tracker  and  Tracker2.  One  can  see  that  a 
Trackables  can  be  renamed  on  the  trackable  option  pane  as  shown  on  the  Figure  43. 

To  send  data  to  the  VRPN  Streamer,  the  Tracking  Tools  Software  must  also  be  configured  to  broadcast  on 
the  VRPN  port.  In  order  to  do  so,  click  on  view  then  click  on  streaming  pane,  then  check  “Broadcast 
VRPN  Data”  as  shown  on  the  Figure  44.  Typically,  the  VRPN  port  used  the  VRPN  Streamer  is  3883.  On 
the  Figure  44,  the  VRPN  streamer  main  window  is  shown.  As  you  can  see,  there  are  data  passing  in  this 
window.  This  means  that  the  VRPN  Streamer  is  sending  vision  data  to  another  computer. 


Figure  44:  Streaming  Pane 


One  can  see  the  data  on  the  VRPN  Streamer  main  window  as  sown  on  the  Figure  44. 
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10.  Configure  the  VRPN  Streamer  to  send  the  data  to  the  QuaRC  Computer 


One  must  realize  that  the  VRPN  Streamer  is  the  key  software  to  send  data  from  the  OptiTrack  computer  to 
the  QuaRC  Computer.  The  VRPN  Streamer  must  be  configured  to  send  trackable  data  to  the  IP  address  of 
the  QuaRC  Computer.  Note  that  the  VRPN  Streamer  is  configured  to  send  UDP  packets  to  networked 
computers.  It  is  possible  to  configure  the  port  number  and  the  IP  address  of  the  destination  by  recompiling 
the  C++  VRPN  Streamer  project.  QuaRC  models  developed  to  use  the  following  UDP  ports:  19000  and 
19001. 


11.  Verify  that  the  QuaRC  computer  receives  the  camera  data. 

Open  the  model  that  is  used  to  receive  the  camera  data  (CamUDP.mdl  is  commonly  used).  Set  the  model 
to  normal  execution  mode  and  click  play.  Verify  that  the  FPS  (Frame  Per  Second)  box  shows  does  not 
show  0.  If  so,  there  a  connection  issue. 

Connection  Issues  can  be: 

•  One  or  more  Network  cable  are  unplugged 

•  IP  addresses  are  not  configured  properly  either  in  the  CamUDP  model  or  in  the  VRPN  Streamer. 

•  The  camera  system  can  not  see  QBots 

•  The  OptiTrack  software  is  not  configured  to  stream  Trackables  on  the  VRPN  port 

•  Trackables  does  not  have  the  right  name. 

Note:  One  must  initialize  constants  required  to  execute  the  model  before  launching  it.  Constants  are 
commonly  located  in  the  Init.m  file. 

Note  that  in  order  to  use  CamUDP.mdl,  it  must  be  executed  once  in  normal  mode  before  being  executed 
in  external  mode.  It  is  sometimes  required  to  launch  the  execution  of  this  model  in  normal  mode  to  reset 
the  connection.  For  example,  sometimes,  CamUDP.mdl  will  fail  to  receive  camera  data  after  a 
compilation. 
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12.  Open  Models  and  Quarc  init.m 


Open  each  models  required  to  the  simulation  you  wish  to  start  and  open  the  corresponding  Quarc  init.m 
script  fde. 

The  reason  to  open  required  .mdl  fdes  and  .m  fdes  at  this  moment  is  simple:  Once  a  computer  is 
disconnected  from  the  Valcartier  network,  the  windows  fde  browser  becomes  very  slow.  Note  that  the 
effectiveness  of  Matlab,  Simulink,  Real-Time  workshop  and  QuaRC  remains  unaffected. 


13.  Open  QBots 

Press  the  power  button.  The  power  led  should  light  up.  If  the  power  is  green,  the  QBot  is  ready.  If  the 
power  led  is  not  green  or  blinking,  refer  to  the  Quanser  QBot  user  manual. 


Play 

Power  Button  Button  Advance  Button 


Power  LED  Play  LED  Advance  LED 


Figure  45: 'QBot  Button  Layout 
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14.  Enable  the  wireless  adapter  on  the  QuaRC  computer 

Since  a  computer  with  a  wireless  adapter  should  never  be  connected  to  the  Valcartier  network,  one  would 
have  to  unplug  the  Valcartier  network  while  preserving  a  local  network  composed  of  the  QuaRC 
computer,  the  X-Plane  computer  and  the  OptiTrack  computer.  The  network  configuration  is  shown  on  the 
Figure  46.  It  is  obvious  that  the  red  arrow  represents  an  Ethernet  cable  that  connects  the  local  network  to 
the  Valcartier  network.  By  simply  removing  this  Ethernet  cable,  it  is  now  allowed  to  enable  the  wireless 
adapter  on  the  QuaRC  computer.  When  you  do  so,  the  IP  address  of  all  computers  will  remain  unchanged. 
It  is  then  possible  to  use  the  IP  address  of  your  computers  even  they  are  not  connected  to  the  Valcartier 
domain. 


Important  Note: 

•  It  is  important  that  the  QuaRC  computer,  the  X-Plane  computer  and  OptiTrack  computer  stay  connected 
since  they  need  to  exchange  data  during  the  simulation. 

•  The  Valcartier  network  assigns  computer  IP  addresses  when  a  user  logs  in.  It  is  then  important  that  the 
user  logs  in  before  disconnecting  the  Valcartier  network. 

Once  the  wireless  adapter  is  enabled,  make  sure  to  connect  to  the  wireless  ad-hoc  network  called  GSAFI. 
GSAFI  is  an  ad-hoc  network  broadcasted  by  QBots  when  they  are  running. 


QuaRC  Computer  Qbot 


X-Plane  OptiTrack 

Computer  Computer 


Figure  46:  Network  Management 
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15.  Verify  that  QBots  are  connected  to  QuaRC  computers  and  open  remote  consoles 

One  easy  way  to  verify  that  QBots  are  eonneeted  to  the  QuaRC  eomputer  is  to  open  a  remote  eonsole  on 
eaeh  QBot. 


8:36  AM 


Friday 

5/15/2009 


Figure  47:  QuaRC  Monitor 


To  aeeess  the  eonsole  on  a  target  that  is  mnning  on  another  eomputer  or  even  on  the  QBot,  you  ean  use 
the  remote  eonsole. 

•  Cliek  on  the  QuaRC  monitor  loeated  in  the  task  bar  (see  the  Figure  47) 

•  Expand  the  Target  tab 

•  Cliek  on  Remote . . . 

•  Enter  the  Target  URJ  (QBots  IP  Addresses  are  written  on  QBots).  The  tepip  protoeol  must  be  used  to 
reaeh  a  remote  target.  The  port  17000  is  always  used  to  eonneet  to  a  target.  For  example,  use  the 
following  URI:  tepip://l  82. 1 68. 1 .200: 1 7000. 

•  Cliek  OK 

•  Verify  that  the  gray  Q  passes  to  green  and  has  no  exelamation  mark.  If  there  is  and  exelamation  mark, 
the  QuaRC  monitor  is  attempting  to  eonneet  to  the  target. 

•  Cliek  again  on  the  QuaRC  monitor 

•  Cliek  Console. . . 

•  Now  you  have  aeeess  to  the  remote  eonsole. 

•  More  than  one  QuaRC  monitor  ean  be  opened  at  a  time.  This  means  that  you  ean  open  a  remote  eonsole 
on  as  many  targets  as  you  want.  To  open  a  new  monitor,  eliek  on  the  Start  menu  ->  All  Programs  -> 
Quanser  ->  QuaRC  ->  Monitor 


r*  QuaRC  Console  for  *  at  tepip: //APS ERTCLUSTER:  1 7000 

»»  starting  the  model  ** 

Creating  main  thread  uith  priority  2  and  period  0.001... 

-  model  ’Target2'  loaded  - 

Entered  main<argc=10,  argo =00862940) 

argu[0]  =  C:\Documents  and  SettingsSflll  UsersNfipplication  Data\QuaRC\spool\win 
dous\Target2 .exe 
argoEl]  =  -w 
argM[2]  =  -d 

argo  t3 ]  =  C:\projectsSQuarc\QuadRotor\Demos\QuadRotorJault_Detect_Joystick_3o 
nTargetl_3on Target 2 
argo[4]  =  -uri 

argoCBl  =  tcpip://10. 10. 10. 4:17003 
argute]  =  -SERUER3 

argut?]  =  tcpip://10. 10. 10. 4:18003 

argu[8]  =  -SERUERl 

argu[9]  =  tcpip://10. 10. 10. 4:18001 

Oaiting  for  start  packet  from  host. 

starting  the  model  ** 

Creating  main  thread  uith  priority  2  and  period  0.001... 

Campling  rate  is  too  fast  for  base  rate 
Sampling  rate  is  too  fast  for  base  rate 


Figure  48:  QuaRC  Cousole 
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16.  Launch  Quarc  init.m 

Open  each  Simulink  models  required  to  the  simulation  you  wish  to  start  and  open  the  corresponding 
Quarc  init.m  script  fde. 

Quarc  init.m  is  specifically  made  to  build  models,  load  and  execute  models,  initialize  constants  and 
define  model  arguments.  Note,  there  is  one  Quarc  init.m  file  for  each  simulations.  Indeed,  communication 
parameters  are  different  for  different  simulation  models. 

For  more  information  about  the  Quarc  init.m  script  file,  refer  to  the  Annex  8. 


Annex  5:  Configuring  the  VRPN  Streamer  Listening  port  and  Broadcasting  port 

The  VRPN  streamer  is  a  relay  between  the  Tracking  Tools  software  and  the  QuaRC  computer.  The  VRPN 
streamer  must  then  be  connected  to  the  Tracking  Tools  software  and  to  the  QuaRC  computer. 

In  order  to  connect  the  VRPN  Streamer  to  the  Tracking  Tools  software,  the  VRPN  Streamer  must  listen  to 
the  same  VRPN  port  that  Tracking  Tools  uses  to  broadcast  visual  data.  Typically,  the  Tracking  Tools 
software  uses  the  VRPN  port  #  3883. 

In  order  to  connect  the  VRPN  Streamer  to  the  QuaRC  computer,  it  must  send  data  to  the  QuaRC 
computer’s  IP  address  and  configured  UDP  ports. 

Both  changing  the  VRPN  listening  port  and  the  UDP  streaming  address  and  port  requires  recompiling  the 
VRPN  C++  project. 


To  change  the  IP  address  or  the  port  on  which  to  send  data,  simply  modify  the  following  line  of  the 
VRPN-Listener.cpp  file  : 

string  tIP  =  "131.132.57.12";  //  IP  du  PC  executant  xPC  Target 
unsigned  short  tPORT  =  19000;  //  Port  UDP  utilise  sur  le  PC  executant 

xPC  Target 

unsigned  short  tPORTl  =  19001; 


Where:  131.132.57.12  is  the  IP  address  of  the  computer  that  will  receive  the  UDP  data  (QuaRC 
computer).  UDP  ports  used  here  are  19000  and  19001.  There  are  2  ports  used  here  because  the  VRPN 
Stream  can  handle  2  rigid  bodies  (Tracker  and  Tracker2  by  default).  Rigid  bodies  must  be  called  Tracker 
and  Tracker2  in  the  OptiTrack  software. 


To  modify  the  VRPN  port  on  which  this  program  listens,  modify  these  lines  of  the  VRPN-Listener.cpp 
file: 

if (UseUDP) 

connection  =  new  vrpn  Connection ( "localhost" ,  3883); 

else 

connection  =  new  vrpn  Connection ( "tcp :/ /localhost" ,  3883); 

The  VRPN  port  used  here  is  3883. 

To  modify  the  rigid  bodies’  name,  modify  the  following  lines: 

vrpn  Tracker  Remote  *tracker2  =  new  vrpn  Tracker  Remote ( "Tracker2 " , 
connection) ; 
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vrpn  Tracker  Remote  *tracker  =  new  vrpn  Tracker  Remote ( "Tracker" , 
connection) ; 

Where:  Tracker  and  Tracker2  are  the  rigid  bodies  names  used  in  the  Tracking  Tools  software. 
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Annex  6:  Configuring  X-Plane 


The  Figure  49  shows  the  X-Plane  bloek  parameters.  As  you  ean  see,  the  IP  Address  of  the  X-Plane 
eomputer  is  required.  The  seeond  parameter  allows  the  user  to  set  the  number  of  planes  to  plot  in  X-Plane. 
Note  that  the  maximum  number  of  planes  is  10  with  the  X-Plane  version  8.40.  The  third  parameter  is  the 
deeimation  whieh  is  used  to  reduee  the  amount  of  data  sent  to  X-Plane.  Indeed  the  deeimation  is  simply  a 
seale  of  down  sample.  Indeed,  if  the  deeimation  is  10,  vehieles  position  will  be  update  10  times  less  often 
than  they  are  ealeulated  by  the  simulation  model.  The  fourth  parameter  is  the  3D  aireraft  X-Plane  models 
(.aef  files)  whieh  will  be  used  to  display  UAVs  in  the  three  dimensional  environment.  Eaeh  aef  file  is 
loeated  in  the  X-Plane  installation  folder. 


Figure  49:  X-Plane  Bloek  Parameters 
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Annex  7 :  Synchronizing  QuaRC  Models 

When  a  simulation  is  distributed  into  more  than  one  model,  each  model  may  require  to  be  started  at  the 
same  time.  Since  every  models  are  started  sequentially,  models  must  be  enabled  when  model  are  loaded. 
In  order  to  start  models  at  the  same  time,  models  are  composed  of  enabled  subsystems.  These  subsystems 
are  enabled  when  every  model  are  loaded  (or  connected).  This  will  ensure  that  there  is  no  delay  between 
each  enabled  subsystems.  The  Figure  50  shows  an  enabled  subsystem  which  the  trigger  signal  indicates 
that  each  communication  blocks  are  connected  and  exchanging  data. 

As  an  example,  if  there  is  a  simulation  composed  of  2  Simulink  models  (model  A  and  model  B).  The 
model  A  contains  an  UAV  which  leads  a  formation.  The  model  B  contains  UAVs  following  the  leader.  If 
the  synchronization  is  not  done  between  the  model  A  and  the  model  B,  it  is  easy  to  see  that  if  the  model  B 
is  started  first,  followers  model  will  be  executed  before  the  leader’s  model.  It  is  easy  to  see  that  a  similar 
problem  will  occur  if  the  model  A  is  started  first.  A  synchronization  is  then  required. 
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Annex  8:Quarc_init.m 


There  are  several  reasons  for  using  Quare  init.m.  For  instanee,  when  exeeuting  more  than  one  model  at  a 
given  time  (distributed  simulations),  it  is  required  to  input  default  model  and  target  URI  manually  in  the 
QuaRC  preferenees  between  eaeh  eompilation  and  exeeution.  By  proeeeding  that  way,  one  would  need  to 
wait  until  a  model  is  loaded  to  a  target,  then  ehange  the  default  model  and  target  URI  for  the  next  model 
in  order  to  load  it.  Proeeeding  that  way  is  time  ineffieient  and  induees  many  eonfiguration  mistakes.  For 
sueh  a  reason,  Quare  init.m  has  been  developed  to  automatize  the  proeess  of  building,  assigning  URIs 
and  loading  models. 

To  build  a  model,  you  must  follow  a  speeifie  order  of  operations: 

•  Defining  the  model  and  the  target  default  URI 

•  Build  and  load  the  model 

•  Conneet  to  the  model 

•  Start  the  model 

Eaeh  of  these  steps  is  done  by  the  Quare  init.m  seript  file. 


%  Target,  Model  and  Server  Configuration 


%apseporcoop  -  182.168.1.100 

%QBOT  -  182.168.1.202 

%close  all 
%clear  all 

%%  Constant  definition  these  files  are  different  for  each  models 

LTAVNOVR_PLOTS 

Init 

%%  Targets  configuration 

%Set  the  number  of  target  to  0  (do  not  edit) 
nTarget=0 ; 

%Define  servers  that  will  be  used  by  the  comm  blocks 
Serverl  =  '-SERVERl  tcpip : / / 1 82 . 1 68 . 1 . 2 02  : 1 8001  '  ; 

Server2  =  '-SERVER2  tcpip : / / 1 82 . 1 68 . 1 . 2 02  : 1 8002  '  ; 

Server6  =  '-SERVER6  tcpip :// 1 82 . 1 68 . 1 . 202 : 1 8003  '  ; 

%%  Model  1 

%Increase  the  number  of  target  by  1 
nTarget  =  nTarget+1; 

%Name  of  the  model 

ConfigStruct .Modelinfo (nTarget) .Name  =  'CamUDP'; 

%Model  URI  -  Since  the  model  is  executed  on  the  machine  that  compile 
and 

%lauche  the  execution,  the  shared  memory  can  be  used 

ConfigStruct .Modelinfo (nTarget) .ModelUri  =  ' shmem: //quarc-target : II ' ; 

%Target  URI  -  Since  the  model  is  executed  on  the  machine  that  compile 
and 

%lauche  the  execution,  the  shared  memory  can  be  used 
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ConfigStruct .Modelinfo (nTarget) .TargetUri  =  ' shmem: //quarc- target : 1 ' ; 

%Define  the  target  type  -  This  one  is  executed  on  a  windows  machine 
ConfigStruct .Modelinfo (nTarget) . TargetType  =  'windows'; 

%The  protocol  used  to  communicate  with  the  target  is  shared  memory 
ConfigStruct .Modelinfo (nTarget) . Protocol  =  'shmem'; 

%This  model  only  uses  the  Server  6  to  communicate  with  the  QBot 
ConfigStruct .Modelinfo (nTarget) .Arguments  =  sprintf ( ' %s ' ,  Server6) ; 

%Always  set  this  to  Yes,  it  is  used  to  stop  the  model  with  Quarc_stop.m 
% (Yes/No) 

ConfigStruct . Modelinfo (nTarget ). Running  =  'Yes'; 

%Decide  wether  you  wish  to  stay  connected  with  the  model  during  the 
%execution  (Yes/No) 

ConfigStruct .Modelinfo (nTarget) . StayConnected  =  'Yes'; 

%Decide  if  that  model  needs  to  be  compiled  (Yes/No) 

ConfigStruct .Modelinfo (nTarget) . Compile  =  'No'; 

%%  Model  2 

%Increase  the  number  of  target  by  1 
nTarget  =  nTarget+1; 

%Name  of  the  model 

ConfigStruct  .Modelinfo  (nTarget)  .Name  =  'ALTAV; 

%Model  URI  -  Since  the  model  is  executed  on  the  machine  that  compile 
and 

%lauche  the  execution,  the  shared  memory  can  be  used 

ConfigStruct .Modelinfo (nTarget) .ModelUri  =  ' shmem: //quarc-target : 12 ' ; 

%Target  URI  -  Since  the  model  is  executed  on  the  machine  that  compile 
and 

%lauche  the  execution,  the  shared  memory  can  be  used 

ConfigStruct .Modelinfo (nTarget) .TargetUri  =  ' shmem: //quarc-target : 1 ' ; 

%Define  the  target  type  -  This  one  is  executed  on  a  windows  machine 
ConfigStruct .Modelinfo (nTarget) . TargetType  =  'windows'; 

%The  protocol  used  to  communicate  with  the  target  is  shared  memory 
ConfigStruct .Modelinfo (nTarget) . Protocol  =  'shmem'; 

%This  model  uses  the  Server  1  and  the  Server  2  to  communicate  with  the 
%Qbot_Control  model 

ConfigStruct .Modelinfo (nTarget) .Arguments  =  sprintf (' %s ' ,  Serverl,'  ', 
Server2 ) ; 

%Always  set  this  to  Yes,  it  is  used  to  stop  the  model  with  Quarc_stop.m 
% (Yes/No) 

ConfigStruct .Modelinfo (nTarget) . Running  =  'Yes'; 

%Decide  wether  you  wish  to  stay  connected  with  the  model  during  the 
%execution  (Yes/No) 

ConfigStruct .Modelinfo (nTarget) . StayConnected  =  'Yes'; 

%Decide  if  that  model  needs  to  be  compiled  (Yes/No) 

ConfigStruct . Modelinfo (nTarget ). Compile  =  'No'; 

%%  Model  3 

%Increase  the  number  of  target  by  1 
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nTarget  =  nTarget+1; 

%Name  of  the  model 

ConfigStruct .Modelinfo (nTarget) .Name  =  ' Qbot_Control ' ; 

%Model  URI  -  Since  the  model  is  executed  on  the  Qbot  you  have  to  use 
the 

%tcpip  protocol  to  communicate  with  it 

ConfigStruct .Modelinfo (nTarget) .ModelUri  = 

' tcpip:/ /1 82. 168. 1.202: 17003 ' ; 

%Target  URI  -  Since  the  model  is  executed  on  the  Qbot  you  have  to  use 
the 

%tcpip  protocol  to  communicate  with  it 

ConfigStruct .Modelinfo (nTarget) .TargetUri  = 

' tcpip: //1 82. 168. 1.202: 17 000 ' ; 

%Define  the  target  type  -  This  one  is  executed  on  a  linux_arm  machine 
% (The  Qbot  board  is  a  linux  arm  machine) 

ConfigStruct .Modelinfo (nTarget) . TargetType  =  ' linux_arm ' ; 

%The  protocol  used  to  communicate  with  the  target  is  tcp 
ConfigStruct .Modelinfo (nTarget) . Protocol  =  'tcpip'; 

%The  Qbot  Use  the  Server  1  and  Server  2  to  communicate  with  the  Altav 
model 

%and  the  Server  6  to  communicate  with  the  CamUDP  model 

ConfigStruct .Modelinfo (nTarget) .Arguments  =  sprintf ( ' %s ' ,  Serverl,' 
',Server2,'  ',  Server6) ; 

%Always  set  this  to  Yes,  it  is  used  to  stop  the  model  with  Quarc_stop.m 
% (Yes/No) 

ConfigStruct . Modelinfo (nTarget ). Running  =  'Yes'; 

%Decide  wether  you  wish  to  stay  connected  with  the  model  during  the 
%execution  (Yes/No) 

ConfigStruct .Modelinfo (nTarget) . StayConnected  =  'Yes'; 

%Decide  if  that  model  needs  to  be  compiled  (Yes/No) 

ConfigStruct .Modelinfo (nTarget) . Compile  =  'No'; 

%%  Building,  loading  models 

%Display  the  number  of  model 
nTarget 

%For  each  model,  compile  if  requested 
for  i=l:nTarget 

if ( strcmp (' Yes ', ConfigStruct . Modelinfo ( i ). Compile) )  %Verify  if  the 
compilation  is  requested 

qc_set_def ault_target_uri (ConfigStruct .Modelinfo (i) . Protocol, 
ConfigStruct .Modelinfo (i) . TargetUri)  %Set  the  target  URI 

qc  set  default  model  uri (ConfigStruct .Modelinfo (i) .ModelUri) 
%Set  the  model  URI 

qc  build  model (ConfigStruct .Modelinfo (i) .Name)  %Build  the  model 

end 

end 


%  Execute  models 
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%Load  and  execute  each  model 
for  i=l:nTarget 

qc_set_def ault_target_uri (Conf igStruct .Modelinfo (i) . Protocol, 
ConfigStruct .Modelinfo (i) . TargetUri)  %Set  the  target  URI 

qc  set  default  model  uri (ConfigStruct .Modelinfo (i) . TargetType, ConfigStr 
uct .Modelinfo (i) .ModelUri)  %Set  the  model  URI 

qc  load  model (ConfigStruct .Modelinfo (i) .Name, sprintf (' %s -w  -d  %d 
-uri  %u','  ', ConfigStruct .Modelinfo (i) .Arguments) )  %Load  the  model  with 

the  proper  arguments 

qc  connect  model (ConfigStruct .Modelinfo (i) .Name)  %  Connect  to  the 
model 

qc  start  model (ConfigStruct .Modelinfo (i) .Name)  %  Start  the  model 

if  ~strcmp (ConfigStruct .Modelinfo (i) . StayConnected,  'Yes') 
qc  disconnect  model (ConfigStruct .Modelinfo (i) .Name) ; 

%Disconnect  if  requested 
end 


end 


86 


UNCLASSIFIED 

SECURITY  CLASSIFICATION  OF  FORM 
(Highest  Classification  of  Title,  Abstract,  Keywords) 


DOCUMENT  CONTROL  DATA 


3.  TITLE  (Its  classification  should  be  indicated  by  the  appropriate  abbreviation  (S,  C,  R  or  U) 

Real-time  Simulations  using  QuaRC  and  RT-LAB  and  Development  of  a  Hardware-in-the-Loop  Indoor  Facility  for  Robot 
Formations 

4.  AUTHORS  (Last  name,  first  name,  middle  initial.  If  military,  show  rank,  e.g.  Doe,  Maj.  John  E.) 

Alexandre  Morris,  Pierre  Gosselin 


6a.  NO.  OF  PAGES 
96 


7.  DESCRIPTIVE  NOTES  (the  category  of  the  document,  e.g.  technical  report,  technical  note  or  memorandum.  Give  the 
inclusive  dates  when  a  specific  reporting  period  is  covered.) 

Contract  report  CR  2009-499 


8.  SPONSORING  ACTIVITY  (name  and  address) 


1 1 .  DOCUMENT  AVAILABILITY  (any  limitations  on  further  dissemination  of  the  document,  other  than  those  imposed  by  security 
classification) 

IXI  Unlimited  distribution 

□  Restricted  to  contractors  in  approved  countries  (specify) 

□  Restricted  to  Canadian  contractors  (with  need-to-know) 

□  Restricted  to  Government  (with  need-to-know) 

□  Restricted  to  Defense  departments 

I  I  Others 

12.  DOCUMENT  ANNOUNCEMENT  (any  limitation  to  the  bibliographic  announcement  of  this  document.  This  will  normally 
correspond  to  the  Document  Availability  (11).  However,  where  further  distribution  (beyond  the  audience  specified  in  11)  is 
possible,  a  wider  announcement  audience  may  be  selected.) 

Unlimited 


9b.  CONTFLACT  NO. 


10b.  OTHER  DOCUMENT  NOS 

N/A 


9a.  PROJECT  OR  GRANT  NO.  (Please  specify  whether  project  or 
grant) 


10a.  ORIGINATOR’S  DOCUMENT  NUMBER 


6b  .NO.  OF  REFERENCES 
14 


5.  DATE  OF  PUBLICATION  (month  and  year) 
September  2009 


2.  SECURITY  CLASSIFICATION 

(Including  special  warning  terms  if  applicable) 

UNCLASSIFIED 


1.  ORIGINATOR  (name  and  address) 
Numerica  Technologies  Inc 


dcd03e  rev.(10-1999) 


UNCLASSIFIED 

SECURITY  CLASSIFICATION  OF  FORM 
(Highest  Classification  of  Title,  Abstract,  Keywords) 


UNCLASSIFIED 

SECURITY  CLASSIFICATION  OF  FORM 
(Highest  Classification  of  Title,  Abstract,  Keywords) 


dcd03e  rev.{10-1999) 


Defence  R&D  Canada 


R  &  D  pour  la  defense  Canada 


Canada's  Leader  in  Defence 
and  National  Security 
Science  and  Technology 


Chef  de  file  an  Canada  en  matiere 
de  science  et  de  technologic  pour 
la  defense  et  la  securite  nationale 


DEFENCE 


www.drdc-rddc.gc.ca 


